Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On Windows 11, openclaw node 2026.5.18 pairs and connects to a Linux 2026.5.18 gateway as node-host/node, but openclaw nodes describe reports Commands: (none reported), so system.which and system.run cannot be invoked.

Steps to reproduce

1. Start OpenClaw gateway 2026.5.18 on a Linux VPS.
2. On Windows 11, run openclaw node install --host <gateway-host> --port 443 --tls --display-name "Legion" --force.
3. Start the scheduled task and approve the fresh pairing request on the gateway.
4. Run openclaw nodes describe --node Legion on the gateway.
5. Run openclaw nodes invoke --node Legion --command system.which --params {"bins":["powershell.exe"]}.

Expected behavior

The Windows headless node host should expose system.which, system.run.prepare, and system.run, as documented for openclaw node.

Actual behavior

openclaw nodes describe --node Legion shows Client: node-host/node and Commands: (none reported). openclaw nodes invoke --node Legion --command system.which --params '{"bins":["powershell.exe"]}' fails with GatewayClientRequestError: node command not allowed: the node did not declare any supported commands.

OpenClaw version

2026.5.18

Operating system

Gateway: Ubuntu 24.04.4 LTS; node: Windows 11

Install method

npm global; Windows node via openclaw node install Scheduled Task

Model

NOT_ENOUGH_INFO

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Gateway config explicitly included: `{"gateway":{"nodes":{"allowCommands":["system.which","system.run"]}}}`

Observed after clean re-pair:
- `openclaw nodes status`: `Known: 1 · Paired: 1 · Connected: 1`
- `openclaw nodes describe --node Legion`: `Client: node-host/node`, `Status: paired · connected`, `Commands: (none reported)`
- `openclaw nodes invoke --node Legion --command system.which --params {"bins":["powershell.exe"]}`: `GatewayClientRequestError: node command not allowed: the node did not declare any supported commands`

Impact and severity

Affected: Windows headless node-host connections to a remote gateway
Severity: High (blocks remote command execution entirely)
Frequency: 100% in the observed repro after clean re-pair
Consequence: system.which / system.run cannot be used on the connected Windows node

Additional information

We ruled out version mismatch, stale pairing state, stale node/device records, and missing gateway allowlist. After a full clean re-pair, the node still connected as node-host/node with no reported commands. Local source inspection also suggested the node-host connect path should advertise system.which, system.run.prepare, and system.run.