Bug type

Behavior bug (incorrect output/state without crash)

Summary

All CLI subcommands that connect to gateway via WebSocket fail with handshake-timeout after ~3 seconds, even though openclaw gateway status shows RPC probe: ok and TCP connect to the gateway port succeeds. Affected commands include openclaw cron add, openclaw cron list, etc.

Steps to reproduce

1. openclaw gateway start on Windows
2. Verify openclaw gateway status → RPC probe: ok, Listening: 127.0.0.1:18789
3. Run openclaw cron add --name test --every 15m --message "test"
4. Observe handshake timeout error after ~3 seconds
5. Consistent across gateway restarts and system reboots
6. TCP connect to port 18789 succeeds (verified via PowerShell TcpClient)

Expected behavior

CLI subcommands should successfully connect to the gateway WebSocket and complete the operation. The gateway is running and responding to HTTP RPC probes.

Actual behavior

CLI fails with handshake timeout. Gateway logs show:

gateway/ws WARN: handshake timeout conn=xxx remote=127.0.0.1
gateway/ws WARN: closed before connect ... cause=handshake-timeout handshakeMs=3004 code=1000
gateway connect failed: Error: gateway closed (1000):
Error: gateway closed (1000 normal closure): no close reason

OpenClaw version

2026.3.13 (61d171a)

Operating system

Windows Server 2022 (10.0.22621, x64)

Install method

npm global

Model

anthropic/claude-opus-4-6

Provider / routing chain

openclaw -> anthropic (direct)

Additional provider/model setup details

Gateway config: loopback mode (127.0.0.1:18789), auth.mode=token. Channel: Feishu. Node v24.14.0.

Logs, screenshots, and evidence

Gateway log signature:

gateway/ws WARN: handshake timeout conn=xxx remote=127.0.0.1
gateway/ws WARN: closed before connect ... cause=handshake-timeout handshakeMs=3004 code=1000


`openclaw doctor` reports no gateway issues. TCP connect to port 18789 succeeds.

Impact and severity

Affected: Windows users running CLI commands against a local gateway
Severity: High (blocks all CLI-to-gateway operations like cron management)
Frequency: 100% reproducible
Consequence: Cannot manage cron jobs or use any CLI subcommand that requires gateway WebSocket connection

Additional information

Workaround: Manually editing ~/.openclaw/cron/jobs.json and restarting the gateway to reload cron configuration.

The gateway is actively processing Feishu channel messages during the failure — concurrent WebSocket connections may be queued/blocked. Adding --token <gateway_auth_token> to the CLI command does not help.