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