Environment
- OpenClaw:
2026.3.13 (61d171a)
- OS: Windows 10 (x64), Node
24.13.1
- Gateway mode:
local
- Bind:
loopback
- Auth mode:
token
- Gateway URL:
ws://127.0.0.1:18789
Summary
I’m seeing contradictory gateway/auth behavior on the same machine/session:
openclaw gateway status reports service running, listener active, and RPC probe: ok.
openclaw status reports:
Gateway ... unreachable (missing scope: operator.read)
openclaw gateway probe fails to connect to the same loopback target (timeout).
This persists across restarts and token/device cleanup.
Repro
- Start gateway:
- Run:
openclaw gateway status
openclaw status
openclaw gateway probe
Observed
gateway status:
- listener active on
127.0.0.1:18789
RPC probe: ok
status:
missing scope: operator.read
gateway probe:
Reachable: no, connect timeout on ws://127.0.0.1:18789
Log evidence
From %LOCALAPPDATA%\Temp\openclaw\openclaw-2026-03-19.log:
- Repeated status-path denials:
errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
- methods:
status, system-presence, config.get
- Intermittent handshake failures:
cause=handshake-timeout
closed before connect with code 1000 or 1006
What I already tried
- Rotated operator token explicitly including
operator.read
- Normalized local auth state files:
~/.openclaw/identity/device-auth.json
~/.openclaw/devices/paired.json
- Reduced paired devices to only one CLI device with full operator scopes
- Cleared browser site data (to remove stale control-ui token mismatch)
- Repeated
gateway stop/start/restart
- Hard-killed gateway process and restarted
Issue persists.
Why this looks like a bug
There appears to be auth/session-path divergence:
- Same runtime says
RPC probe: ok
- while probe/status paths fail with scope timeout/denial on same endpoint and same token config.
Could be stale claim resolution or split auth handling between CLI command paths.
Request
Please advise:
- Why
status/system-presence/config.get are evaluated without operator.read despite local paired/token state including it.
- Why
gateway probe can timeout while gateway status reports RPC probe OK on same loopback endpoint.
- Whether there is a hidden auth/session cache reset command beyond device token rotate + service restart.
Environment
2026.3.13 (61d171a)24.13.1localloopbacktokenws://127.0.0.1:18789Summary
I’m seeing contradictory gateway/auth behavior on the same machine/session:
openclaw gateway statusreports service running, listener active, andRPC probe: ok.openclaw statusreports:Gateway ... unreachable (missing scope: operator.read)openclaw gateway probefails to connect to the same loopback target (timeout).This persists across restarts and token/device cleanup.
Repro
Observed
gateway status:127.0.0.1:18789RPC probe: okstatus:missing scope: operator.readgateway probe:Reachable: no, connect timeout onws://127.0.0.1:18789Log evidence
From
%LOCALAPPDATA%\Temp\openclaw\openclaw-2026-03-19.log:errorCode=INVALID_REQUEST errorMessage=missing scope: operator.readstatus,system-presence,config.getcause=handshake-timeoutclosed before connectwith code1000or1006What I already tried
operator.read~/.openclaw/identity/device-auth.json~/.openclaw/devices/paired.jsongateway stop/start/restartIssue persists.
Why this looks like a bug
There appears to be auth/session-path divergence:
RPC probe: okCould be stale claim resolution or split auth handling between CLI command paths.
Request
Please advise:
status/system-presence/config.getare evaluated withoutoperator.readdespite local paired/token state including it.gateway probecan timeout whilegateway statusreports RPC probe OK on same loopback endpoint.