Bug type

Regression (worked before, now fails)

Summary

Issue: CLI Cannot Connect to Gateway – Downgrading from 2026.3.13 to 2026.3.11 Resolves the Problem

Environment

• OS: Ubuntu 24.04.4 LTS (Linux 6.8.0-101-generic x86_64)
• Node: 22.22.1
• Problematic version: OpenClaw 2026.3.13
• Working version: OpenClaw 2026.3.11
• Installation: npm global (user: openclaw, non‑root)
• Gateway: local loopback, port 18789, token auth

Description
In version 2026.3.13, the CLI fails to connect to the Gateway. Running openclaw status repeatedly reports:

• Gateway · unreachable (missing scope: operator.read)
• or gateway timeout after 10000ms

However, the Gateway service itself is running (systemd active), and both the browser Dashboard and wscat can successfully establish WebSocket connections to the Gateway.

Investigation

• ss -tlnp | grep 18789 confirms listening.
• curl http://127.0.0.1:18789 returns Dashboard HTML – HTTP works.
• wscat ws://127.0.0.1:18789/?token=... connects and receives connect.challenge.
• Manually sending {"type":"auth","payload":{"token":"...","nonce":"..."}} is rejected with invalid request frame.

Key Findings

• The Gateway requires a challenge‑response WebSocket handshake.
• In 2026.3.13, the CLI likely sends an incorrectly formatted auth frame (or fails to include the correct nonce).
• Downgrading to 2026.3.11 resolves the issue completely.

Logs (redacted)
{"0":"{"subsystem":"gateway/ws"}","1":"⇄ res ✗ status 2ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read conn=4fec4c9e…0a0a id=ff0b06af…3e1f", ...}
{"0":"{"subsystem":"gateway/ws"}","1":"⇄ res ✗ system-presence 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read conn=4fec4c9e…0a0a id=0c801eb4…49c5", ...}
{"0":"{"subsystem":"gateway/ws"}","1":"invalid handshake conn=e355d500-eaf0-42bb-a481-602a9b067a55 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789/ host=127.0.0.1:18789 ua=n/a", ...}
{"0":"{"subsystem":"gateway/ws"}","1":{"cause":"invalid-handshake","handshake":"failed","durationMs":18,"lastFrameType":"auth","host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789/","frameType":"auth","handshakeError":"invalid request frame"}, ...}
Suggested Fix
Examine the CLI WebSocket handshake implementation in versions 2026.3.12/13. Ensure it correctly handles the challenge‑response and sends the proper auth frame with nonce.

Reported by
GitHub: @passer593
Email: 14090219@qq.com

Steps to reproduce

Steps to Reproduce
Prepare the environment (using Ubuntu 24.04 as an example):

bash

Ensure Node.js 22+ is installed

node --version # Should output v22.22.1 or higher

Globally install the known working old version 2026.3.11

npm uninstall -g openclaw
npm install -g openclaw@2026.3.11

Initialize and start the Gateway

openclaw gateway install --force
openclaw doctor --fix
systemctl --user restart openclaw-gateway
Verify that the old version works correctly:

bash
openclaw status

Expected output: Gateway shows "reachable", no errors

Upgrade to the problematic version 2026.3.13:

bash
npm install -g openclaw@2026.3.13
systemctl --user restart openclaw-gateway
Trigger the error:

bash
openclaw status

Actual output: Gateway shows "unreachable (missing scope: operator.read)"

or a timeout error "gateway timeout after 10000ms"

Other attempts all fail:

bash

Restart the Gateway

systemctl --user restart openclaw-gateway

Re-run doctor

openclaw doctor --fix

Re-run onboard

openclaw onboard

After the above operations, openclaw status still reports the same error

Downgrading restores functionality:

bash
npm uninstall -g openclaw
npm install -g openclaw@2026.3.11
systemctl --user restart openclaw-gateway
openclaw status # Works again
Additional Notes
If developers need more detailed debugging information, they can run the following before openclaw status:

bash
export DEBUG=openclaw:*
This will output more detailed WebSocket handshake logs.

Expected behavior

After upgrading to OpenClaw 2026.3.13, the CLI should be able to successfully connect to the Gateway, just as it does in the working version 2026.3.11.

Specifically:

Running openclaw status should display the Gateway as reachable, without any errors such as missing scope: operator.read or timeouts.

All CLI commands (e.g., openclaw status, openclaw config.get, and other RPC calls) should execute normally and return the expected information.

The WebSocket handshake between the CLI and Gateway should complete successfully, granting the necessary scopes (like operator.read) so that subsequent requests are not rejected.

In short, the behavior should be identical to that of version 2026.3.11, where the CLI‑to‑Gateway communication works flawlessly. A version upgrade should not break this core functionality.

Actual behavior

After upgrading to OpenClaw 2026.3.13, the CLI fails to connect to the Gateway, exhibiting the following symptoms:

Running openclaw status repeatedly produces errors:

Gateway · unreachable (missing scope: operator.read)

or gateway timeout after 10000ms

Despite the Gateway service itself running normally (verified via systemctl and ss), and the browser Dashboard being accessible via HTTP, all CLI commands that require RPC communication (e.g., status, config.get, system-presence) are rejected with:

text
errorCode=INVALID_REQUEST
errorMessage=missing scope: operator.read
The WebSocket handshake between the CLI and Gateway fails. Logs show:

text
invalid handshake ... frameType="auth" handshakeError="invalid request frame"
Manually connecting with wscat to the Gateway succeeds, but sending the authentication frame with a nonce is also rejected as invalid request frame, indicating a protocol mismatch.

Downgrading back to version 2026.3.11 immediately restores full functionality—openclaw status works correctly and all commands execute as expected.

In summary, version 2026.3.13 breaks the CLI‑to‑Gateway communication due to a faulty WebSocket handshake implementation, while the Gateway itself remains operational.

OpenClaw version

2026.3.13

Operating system

24.04.4 LTS

Install method

npm install -g openclaw

Model

stepfun/step-3.5-flash:free

Provider / routing chain

local Gateway (loopback) → OpenRouter API (model: stepfun/step-3.5-flash:free)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response