feat: surface node reapproval in Command Center

[fuller-stack-dev]

Depends on

Depends on openclaw/openclaw#92547. That core diagnostics PR adds the
optional node.list / node.describe approval-state and pending-declaration
fields consumed here. Land this Windows PR after the core contract.

Summary

• consume approved/effective node capabilities, commands, and permissions
  separately from pending declared surfaces
• show pending approval/reapproval in the visible Command Center connection
  page with a validated, copy-only approval command and manual reconnect action
• keep unsafe or missing request IDs on discovery-only
  openclaw nodes pending guidance
• stop runtime auto-approval of node command-trust requests while preserving
  narrowly typed device-pair role-upgrade autoapproval
• update setup-connect E2E to perform explicit operator node-trust approval,
  explicit node reconnect, and exact effective-surface readiness checks
• preserve the exact same-gateway operator connection during node-only
  reapproval reconnect, then explicitly refresh the visible cached node list
• keep synthesized local declarations visibly unverified rather than
  classifying them as approved/effective
• preserve older-gateway compatibility when the additive fields are absent

Pending declarations never populate effective fields or counts, and the tray
does not auto-approve command trust.

Behavior

• caps, commands, and permissions remain approved/effective only.
• declaredCommands is never treated as effective.
• An authoritative empty caps: [] remains empty; the legacy
  capabilities fallback is used only when caps is absent.
• pending-approval and pending-reapproval replace only ordinary active or
  generic node-pair cards. Device-pair role upgrades and off/error/rejected/
  rate-limited states retain priority.
• Safe pending request IDs produce
  openclaw nodes approve <pendingRequestId>.
• Missing or unsafe request IDs produce discovery-only
  openclaw nodes pending guidance and do not claim to approve anything.
• SetupEngine's explicitly configured onboarding autoapproval flow is unchanged
  and outside this runtime trust-boundary change.
• Setup-connect E2E trust decisions remain explicit test-operator actions in
  SetupAndConnectTests; production node command-trust autoapproval is not
  restored.
• A same-gateway node reapproval reconnect preserves the connected operator so
  it can request the post-handshake node.list; changed gateway URL, record, or
  SSH tunnel still resets the old lifecycle.
• After node-only reconnect, the tray awaits an explicit AppState.Nodes
  refresh so the visible local cache reflects the approved effective surface.

Verification

Initial feature validation, AWS Windows Crabbox provider/id:
aws / cbx_7ee1bb820eff

• run_2edf3909038e
  • focused connection trust tests: 6 passed
  • focused shared parser/model tests: 216 passed
  • focused visible ConnectionPage plan/source tests: 10 passed
• run_56e43890ad02
  • ./build.ps1
  • Shared, CLI, WinNodeCli, SetupEngine, and WinUI built successfully
  • focused shared permission/reapproval tests: 52 passed
  • focused visible Command Center approval/localization tests: 24 passed
  • shared tests: 2252 passed, 29 skipped, 0 failed
  • tray tests: 1074 passed, 0 skipped, 0 failed

Setup-connect E2E follow-up validation, AWS Windows Crabbox provider/id:
aws / cbx_ee15cfc7388e (amber-lobster, m7i.4xlarge)

• run_75ca5456a119
  • ./build.ps1: passed; Shared, CLI, WinNodeCli, SetupEngine, and WinUI built
  • shared tests: 2252 passed, 29 skipped, 0 failed
  • tray tests: 1074 passed, 0 skipped, 0 failed
  • affected E2E project build: passed, 0 warnings, 0 errors
• run_5a40ee52f232
  • exact setup-connect lane executed with 15 tests selected
  • all 15 were blocked in shared fixture setup before test-body execution
    because the AWS m7i.4xlarge host does not expose WSL2 nested
    virtualization (HCS_E_HYPERV_NOT_INSTALLED)

Final reconnect/cache validation, AWS Windows Crabbox provider/id:
aws / cbx_c9d8f40c8339 (golden-hermit, m7i.4xlarge)

• run_ae452aebfe28
  • focused same-gateway lifecycle tests: 6 passed, 0 failed
  • focused visible node-list refresh source test: 1 passed, 0 failed
• run_7495ac86f546
  • ./build.ps1: passed; Shared, CLI, WinNodeCli, SetupEngine, and WinUI built
  • tray tests: 1075 passed, 0 skipped, 0 failed
  • affected E2E project build: passed, 0 warnings, 0 errors
  • exact setup-connect lane selected all 15 tests; all were blocked in shared
    fixture setup because WSL is unavailable on the AWS Windows Server host
• run_16517948e561
  • ./build.ps1: passed; Shared, CLI, WinNodeCli, SetupEngine, and WinUI built
  • shared tests: 2252 passed, 29 skipped, 0 failed
  • tray tests: 1075 passed, 0 skipped, 0 failed
• hosted Windows CI run 27453209336, setup-connect job 81152595877
  • strict setup-connect lane passed in 10m35s
  • proves explicit approval -> reconnect -> external tray cached app.nodes
    refresh reaches the exact approved effective surface
  • hosted test, network-recovery, revocation-recovery, win-x64 packaging, and
    win-arm64 packaging jobs passed
• hosted Windows CI run 27453992205 on exact head 4bdc7b61b72ddf32e302e3e9678f90ff0e5ffab2
  • test, setup-connect, revocation-recovery, network-recovery, win-x64, and
    win-arm64 jobs passed
  • includes the new toast-command and local trust node-list-refresh regression tests
• git diff --check: passed
• final persisted branch autoreview: no remaining accepted/actionable findings
  • fixed the wrong node-trust toast command and stale local trust node-list refresh
  • rejected the reconnect-race finding because NodeConnector.ConnectAsync disposes
    the prior client and generation-guards callbacks
  • rejected the missing node.list fields finding because declared dependency
    fix(nodes): surface pending reapproval diagnostics openclaw#92547 emits the additive fields
• XAML and all changed .resw files parsed with xmllint --noout

An earlier full shared-suite execution (run_4e33375389e2) hit one unchanged
process-global app-version override race; final required shared execution is
green in run_56e43890ad02 and run_75ca5456a119.

Real behavior proof

Behavior addressed: Windows Command Center distinguishes approved/effective
node surfaces from pending declarations, requires explicit command-trust
approval, and setup-connect E2E now models approve -> reconnect -> effective
readiness instead of relying on production autoapproval.

Real environment tested: AWS native Windows Crabbox leases
cbx_7ee1bb820eff, cbx_ee15cfc7388e, and cbx_c9d8f40c8339
(m7i.4xlarge).

Exact steps or command run after this patch: ./build.ps1, focused
trust/parser/visible-plan tests, required shared/tray tests, affected E2E project
build, and dotnet test tests/OpenClaw.E2ETests --no-build -c Debug -r win-x64 --filter "FullyQualifiedName~OpenClaw.E2ETests.Setup.SetupAndConnectTests".

Evidence after fix: build, focused parser/behavior/lifecycle/cache-refresh
tests, complete shared/tray suites, and affected E2E compilation passed.
Setup-connect runs run_5a40ee52f232 and run_7495ac86f546 selected all 15
tests and recorded the AWS WSL environment blocker. Hosted Windows setup-connect jobs 81152595877 and 81154842202 passed the strict external-tray effective-surface assertion.

Observed result after fix: parser and behavior tests prove pending declarations
remain separate from effective surfaces, manual approval commands are validated,
higher-priority/off states are preserved, and the setup-connect harness performs
explicit node-trust approval followed by explicit reconnect and exact-node
effective-surface readiness checks. Same-gateway reconnect preserves the
operator and explicitly refreshes the tray's visible cached node list.

What was not tested: live activation of the new approval/reapproval UI against a
gateway emitting the additive fields until dependency openclaw/openclaw#92547
lands. The full setup-connect operator flow also could not execute on AWS lease
cbx_c9d8f40c8339 because WSL is unavailable on the Windows Server host;
hosted Windows CI supplied that E2E proof.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 13, 2026, 10:54 PM ET / 02:54 UTC.

Summary
The PR separates effective node surfaces from pending declarations, adds Command Center approval/reapproval UI and reconnect refresh behavior, and preserves only typed device-pair role-upgrade autoapproval.

Reproducibility: not applicable. This PR is a feature and workflow change, not a current-main bug report. The changed behavior is source-verifiable in the PR diff and the PR body supplies AWS Windows Crabbox plus hosted CI proof.

Review metrics: 3 noteworthy metrics.

• PR Surface: 39 files changed, +3242/-624. The branch spans connection lifecycle, shared parsing/models, WinUI, localization, docs, and E2E tests, so compatibility review matters.
• Trust Boundary Change: 1 runtime node-pair autoapproval path removed. The central behavior change makes node command-trust approval explicit instead of automatic.
• Exact-Head Checks: 4 in progress in latest metadata. The current head still needs normal Windows test and E2E merge gates to finish.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Let the latest exact-head Windows test and setup-connect jobs finish.
• Keep release or PR-body context explicit for the manual approval and reconnect workflow.

Mantis proof suggestion
A visible Command Center proof would materially help after the core diagnostics contract is available because the PR changes user-visible approval/reapproval UI state. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: verify Command Center shows pending node reapproval with copy-only approval and reconnect refresh.

Risk before merge

• [P1] Existing users who relied on runtime node command-trust autoapproval will need explicit operator approval and reconnect after command-surface changes.
• [P1] The latest PR metadata still showed four exact-head Build and Test jobs in progress on head 318d12cac0b2e6204ec6782ec38b79eba523148b.
• [P1] Live activation of the new UI against a gateway emitting the additive fields depends on the merged core contract being deployed into the tested gateway/runtime path.

Maintainer options:

1. Wait For Exact-Head Gates (recommended)
   Let the latest Windows test and setup-connect jobs complete on the current head before merging the compatibility-sensitive workflow change.
2. Accept The Manual Approval Upgrade
   If maintainers want the stricter trust boundary now, merge with release or PR-body context that changed node command surfaces require manual operator approval and reconnect.
3. Stage A Compatibility Default
   If the operator-action upgrade is too disruptive, pause and split a legacy-compatible default plus explicit strict mode into separate design work.

Next step before merge

• [P2] The remaining action is maintainer sequencing and upgrade-policy acceptance, not a narrow automated repair.

Security
Cleared: No concrete security or supply-chain regression was found; the diff tightens node command-trust approval and does not add dependencies, workflows, or broader secret access.

Review details

Best possible solution:

Land this only after exact-head Windows validation completes and maintainers accept the explicit approval and reconnect upgrade path.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this PR is a feature and workflow change, not a current-main bug report. The changed behavior is source-verifiable in the PR diff and the PR body supplies AWS Windows Crabbox plus hosted CI proof.

Is this the best way to solve the issue?

Yes, conditionally: separating pending declarations from effective surfaces and making node-trust approval explicit matches the trust-boundary goal. The compatibility change still needs maintainer acceptance and exact-head validation before merge.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against ff38d8499c48.

Label changes

Label justifications:

• P1: The PR changes a live Windows node command-trust workflow that can block command-surface updates until an operator acts.
• merge-risk: 🚨 compatibility: Existing setups that depended on runtime node command-trust autoapproval may require a new manual approval and reconnect step after merge.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The PR body includes after-fix AWS Windows Crabbox validation and hosted Windows CI proof for approval, reconnect, cache-refresh, and setup-connect behavior, with the live UI/core-deployment limitation stated.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix AWS Windows Crabbox validation and hosted Windows CI proof for approval, reconnect, cache-refresh, and setup-connect behavior, with the live UI/core-deployment limitation stated.

Evidence reviewed

What I checked:

• AGENTS policy read and applied: The repository policy was read fully and applies because this PR changes connection, pairing, node, and tray UX behavior. (AGENTS.md:34, ff38d8499c48)
• Current main still auto-approves node-pair requests: Current main calls the autoapproval path for pending node pairing events and node-pair list updates, so the explicit operator approval behavior is not already implemented on main. (src/OpenClaw.Connection/GatewayConnectionManager.cs:1247, ff38d8499c48)
• Current main treats declaredCommands as effective fallback: Current main parses declaredCommands into GatewayNodeInfo.Commands before falling back to commands, which is the behavior this PR changes to keep unverified declarations separate. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:3486, ff38d8499c48)
• PR head keeps node command trust explicit: At the PR head, DevicePair requests keep the narrow autoapproval path, while NodePair and unknown command-trust requests are recorded as awaiting explicit operator approval. (src/OpenClaw.Connection/GatewayConnectionManager.cs:1410, 318d12cac0b2)
• PR head separates effective and pending node surfaces: At the PR head, caps, commands, and permissions remain effective fields while pendingDeclared* and pendingRequestId are parsed separately; legacy declaredCommands is kept as unverified when approval fields are absent. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:3483, 318d12cac0b2)
• PR head exposes copy-only trust approval UI: ConnectionPagePlan lets authoritative pending approval or reapproval own the node card, suppresses the generic node approve command, and falls back to openclaw nodes pending when no safe request id is available. (src/OpenClaw.Tray.WinUI/Pages/ConnectionPagePlan.cs:514, 318d12cac0b2)

Likely related people:

• ranjeshj: Recent current-main pairing hardening introduced the node-pair autoapproval path and touched the affected connection/page behavior. (role: recent area contributor; confidence: high; commits: ea36b12f9e4c; files: src/OpenClaw.Connection/GatewayConnectionManager.cs, tests/OpenClaw.Connection.Tests/NodePairAutoApproveTests.cs, src/OpenClaw.Tray.WinUI/Pages/ConnectionPagePlan.cs)
• Barbara Kudiess: Current-main blame and git log -S tie the baseline connection manager, gateway client parser, and connection page plan code to the initial feature commit. (role: baseline code contributor; confidence: medium; commits: 8f134b354df0; files: src/OpenClaw.Connection/GatewayConnectionManager.cs, src/OpenClaw.Shared/OpenClawGatewayClient.cs, src/OpenClaw.Tray.WinUI/Pages/ConnectionPagePlan.cs)
• steipete: The PR is assigned to this reviewer and the latest branch commit is a targeted fix to keep device approval guidance request-bound. (role: recent branch reviewer; confidence: medium; commits: 318d12cac0b2; files: src/OpenClaw.Tray.WinUI/Pages/ConnectionPagePlan.cs, tests/OpenClaw.Tray.Tests/ConnectionPageApproveCommandTests.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[fuller-stack-dev]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/27464170296
• Updated: 2026-06-13T10:34:59.562Z

[steipete]

Land-ready verification for head 318d12cac0b2e6204ec6782ec38b79eba523148b.

• Core dependency landed first in fix(nodes): surface pending reapproval diagnostics openclaw#92547 (65b460f2345a135f22df7631598643002605aad6).
• Maintainer fix 318d12ca keeps device approval guidance request-bound: unsafe/missing request IDs now copy openclaw devices list, and the retired no-op device-pair-list subscription was removed.
• Fresh branch autoreview: clean, patch correct (0.82).
• Fresh final-patch autoreview: clean, patch correct (0.87).
• Exact-head CI: https://github.com/openclaw/openclaw-windows-node/actions/runs/27486351808
  • full test job: passed
  • setup-connect E2E: passed
  • network-recovery E2E: passed
  • revocation-recovery E2E: passed
  • win-x64 build: passed
  • win-arm64 build: passed
• Native Crabbox was attempted. Azure capacity did not allocate (run_edb245f0cc11); AWS allocated cbx_04fea5d61994 / run_55f86cd484e4, but that base Windows image lacked .NET, Node, and the Windows SDK, so it could not duplicate the repository build. The exact-head GitHub Windows runners provide the authoritative native proof above.

The core contract was checked directly in src/shared/node-list-types.ts, src/gateway/node-catalog.ts, src/gateway/node-catalog.test.ts, and gateway pairing handling: effective capabilities remain separate from pending declarations, and pending approval/reapproval stays non-executable until approval.