Environment

• OpenClaw: 2026.3.13 (61d171a)
• Node: v22.22.0
• OS: Debian 12 (bookworm), x86_64
• Install: npm global (npm i -g openclaw)
• Gateway: systemd user service, loopback bind

Problem

After upgrading from v2026.3.12 → v2026.3.13, all CLI commands using the CLI-mode gateway RPC client fail with handshake timeout. Probe-mode commands (status, doctor) still work fine.

2 independent gateways on the same host (different user accounts, different ports) exhibit identical behavior after the upgrade.

Minimal repro

openclaw gateway call health --json
# → "gateway timeout after 10000ms"

Also fails: openclaw devices list, openclaw gateway call device.pair.list --json --params "{}"

Still working (probe/token-auth path):

openclaw status   # ✅
openclaw doctor   # ✅

Gateway log during failure

[ws] handshake timeout conn=9511c15d… remote=127.0.0.1
[ws] closed before connect conn=9511c15d… code=1006 reason=n/a

Debug log (OPENCLAW_LOG_LEVEL=debug)

{"cause":"handshake-timeout","handshake":"failed","durationMs":27462,"host":"127.0.0.1:18791","handshakeMs":3000}

No parse error, no challenge received — the CLI opens the WebSocket but never processes the server's connect.challenge event.

Raw WS client proof

A minimal WS client does receive the challenge immediately:

NODE_PATH=/path/to/openclaw/node_modules node -e \
  "const W=require('ws'); const ws=new W('ws://127.0.0.1:18791'); ws.on('message',m=>console.log(m.toString()))"

Output:

{"type":"event","event":"connect.challenge","payload":{"nonce":"c432338f-...","ts":1773495351042}}

Gateway sends challenge correctly. The OpenClaw CLI binary just never responds to it.

What was ruled out

• PATH / binary mismatch (confirmed same binary via command -v + --version in login shell)
• Proxy vars (none set)
• Device identity corruption (full reset of device.json + device-auth.json + paired.json → same result)
• Quoting / shell expansion (tested via SCP'd script + bash -l, direct binary path call)
• 2 gateways, 2 users, different ports — identical behavior

Additional context

• Upgraded from v2026.3.12 where all CLI commands worked correctly
• gateway.controlUi.dangerouslyDisableDeviceAuth is unrelated (Control UI only, does not affect CLI-mode RPC)
• No operational impact on gateway/channels — Telegram, heartbeat, sessions all work fine