Windows headless node host supports exec approvals via CLI, but nodes describe / Control UI do not advertise system.execApprovals.get/set

[RTKOP]

Environment

• OpenClaw version: 2026.3.28
• Gateway host: macOS
• Remote node host: Windows (win32)
• Node type: headless node host started via openclaw node run

Expected behavior

A Windows headless node host should advertise exec approvals commands, consistent with the docs and implementation:

• system.run
• system.which
• system.execApprovals.get
• system.execApprovals.set

Because of that, the Control UI should recognize the node as an exec-approvals-capable target.

Actual behavior

The Windows node connects successfully and shows as paired + connected.

openclaw nodes describe --node <id> shows only:

• browser.proxy
• system.run
• system.run.prepare
• system.which

It does not show:

• system.execApprovals.get
• system.execApprovals.set

However, the following command works successfully:

openclaw approvals get --node <id>

and correctly returns the remote node host approvals snapshot, including the Windows-side file path and hash.

So exec approvals appear to be implemented and functional, but not surfaced consistently through node command advertisement / describe output.

Reproduction steps

1. Install OpenClaw CLI on Windows
2. Start a Windows headless node host against a reachable gateway
3. Approve pairing so the node becomes connected
4. Run:

openclaw nodes status
openclaw nodes describe --node <id>
openclaw approvals get --node <id>

5. Observe:
   • the node is connected
   • approvals get --node works
   • nodes describe does not list system.execApprovals.get/set

Observed node state

Example node details:

• platform: win32
• caps: browser, system
• commands shown:
  • browser.proxy
  • system.run
  • system.run.prepare
  • system.which

Example approvals state retrieved successfully from the node:

• approvals file exists
• remote path resolves on Windows
• snapshot can be fetched via openclaw approvals get --node ...

Why this looks like a bug

The packaged implementation appears to include both the handler and the advertised command registration for exec approvals on the headless node host.

From the local build:

• the node invoke handler implements:
  • system.execApprovals.get
  • system.execApprovals.set
• node host startup appears to include:
  • ...NODE_SYSTEM_RUN_COMMANDS
  • ...NODE_EXEC_APPROVALS_COMMANDS
  • browser proxy commands

So there seems to be a mismatch between:

• implemented/invokable commands
• advertised/visible commands in nodes describe
• Control UI filtering for exec approvals targets

Impact

• CLI workflows still work
• Control UI does not treat the Windows node as an exec-approvals-capable target
• this makes it appear that Windows headless node hosts do not support exec approvals, even though openclaw approvals get --node ... works

Guess

This may be one of:

1. nodes describe / node status output is dropping system.execApprovals.get/set
2. the node is invokable for approvals, but advertised commands are not propagated consistently
3. Control UI relies on advertised commands, so the mismatch hides valid node targets

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
Keep open: current main still omits the exec approval command IDs from the gateway node command allowlist, so connect reconciliation filters them before nodes describe and the Control UI target picker can see them.

Reproducibility: yes. via source inspection on current main: the node host declares system.execApprovals.get/set, but the gateway allowlist omits those IDs and connect reconciliation filters them before describe/UI consume the command list. I did not run the live Windows handshake.

Next step
This is a narrow source-backed bug with clear gateway/node-host/UI surfaces and no product or config decision required.

Review details

Best possible solution:

Add the exec approval command constants to the desktop node command policy used during pairing/reconnect so advertised commands include them, while keeping direct node.invoke blocked and routing edits through exec.approvals.node.*.

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

Yes, via source inspection on current main: the node host declares system.execApprovals.get/set, but the gateway allowlist omits those IDs and connect reconciliation filters them before describe/UI consume the command list. I did not run the live Windows handshake.

Is this the best way to solve the issue?

Yes. The narrow maintainable fix is policy alignment in the gateway node command allowlist plus regression coverage, not a new UI workaround or a new config option.

Label justifications:

• P2: This is a normal-priority Windows/headless-node bug with a clear source cause and limited blast radius; CLI approvals still work, but describe/UI discovery is wrong.

Acceptance criteria:

• node scripts/run-vitest.mjs src/gateway/node-command-policy.test.ts src/gateway/node-connect-reconcile.test.ts src/gateway/server.roles-allowlist-update.test.ts
• node scripts/run-vitest.mjs src/gateway/server.node-invoke-approval-bypass.test.ts
• node scripts/run-vitest.mjs ui/src/ui/views/nodes.devices.test.ts
• node scripts/crabbox-wrapper.mjs run --shell -- "pnpm check:changed"

What I checked:

• Live issue context: The issue is still open, has no protected labels, and the existing ClawSweeper comment kept it open for the same source-level mismatch rather than linking a fixing PR.
• Docs define the expected node-host surface: The node docs say the headless node host exposes system.run, system.which, and system.execApprovals.get/set. Public docs: docs/nodes/index.md. (docs/nodes/index.md:354, 04eac15f43d5)
• Node host declares exec approval commands: runNodeHost includes NODE_EXEC_APPROVALS_COMMANDS in the GatewayClient command list, and the shared constant expands to system.execApprovals.get and system.execApprovals.set. (src/node-host/runner.ts:276, 04eac15f43d5)
• Node host implements the handlers: The node-host invoke handler has explicit branches for both system.execApprovals.get and system.execApprovals.set, matching the report that the approvals CLI path works. (src/node-host/invoke.ts:368, 04eac15f43d5)
• Gateway allowlist still drops the commands: SYSTEM_COMMANDS includes system run, notify, and browser proxy commands but does not import or include NODE_EXEC_APPROVALS_COMMANDS; Windows defaults include ...SYSTEM_COMMANDS, so the exec approval commands are absent from default advertisement. (src/gateway/node-command-policy.ts:47, 04eac15f43d5)
• Connect reconciliation filters to the allowlist: On node connect, declared commands are normalized through resolveNodePairingCommandAllowlist, so commands missing from the allowlist are removed before pairing/describe state is updated. (src/gateway/node-connect-reconcile.ts:154, 04eac15f43d5)

Likely related people:

• steipete: Introduced the shared node command catalog, extracted node pairing reconciliation, and changed node command propagation around this gateway/node boundary. (role: feature-history owner; confidence: high; commits: d06632ba45a8, db0cea5689ac, f6317fb747f5; files: src/infra/node-commands.ts, src/node-host/runner.ts, src/gateway/node-command-policy.ts)
• shanselman: Authored the recent merged change allowing safe Windows companion node commands in the same policy file adjacent to the missing exec approval defaults. (role: Windows default policy contributor; confidence: medium; commits: 8f277e4b7f4f; files: src/gateway/node-command-policy.ts, docs/nodes/index.md)
• pgondhi987: Recently touched canonical node platform handling and the command-policy/reconciliation paths that decide which node commands survive connect. (role: recent area contributor; confidence: medium; commits: d656087b3156; files: src/gateway/node-command-policy.ts, src/gateway/node-connect-reconcile.ts, src/gateway/server-methods/nodes.ts)

Remaining risk / open question:

• I did not run a live Windows node-host handshake in this read-only pass, so the proof is source-level rather than live transport proof.
• A fix must preserve the existing direct node.invoke rejection for system.execApprovals.*; approval editing should continue through exec.approvals.node.*.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 04eac15f43d5.