Summary
openclaw status and gateway probe report missing scope: operator.read on a loopback gateway with token auth mode, even though gateway call --token <token> works correctly. The probe/status client path doesn't negotiate operator scopes properly.
Steps to reproduce
- Configure gateway with
auth.mode: "token" and a token in openclaw.json
- Gateway running on loopback (
bind: "loopback", port 18789)
- Run
openclaw status → Gateway row shows unreachable (missing scope: operator.read)
- Run
openclaw gateway probe --token <token> → same missing scope: operator.read
- Run
openclaw gateway call status --token <token> → works fine, returns full status JSON
Expected behavior
openclaw status should read the gateway token from config and connect with operator.read scope. At minimum, gateway probe --token <token> should work when the token is passed explicitly.
Actual behavior
openclaw status: no --token option, doesn't read token from config for scope negotiationgateway probe --token <token>: accepts the flag but still fails with missing scope: operator.readgateway call status --token <token>: works correctly
Gateway logs confirm the scope error on every status/system-presence/config.get RPC:
[ws] ⇄ res ✗ status 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
[ws] ⇄ res ✗ system-presence 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
[ws] ⇄ res ✗ config.get 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
Workarounds attempted (none resolved it)
openclaw gateway install --force + restartOPENCLAW_GATEWAY_TOKEN env vargateway probe --token <token>gateway.controlUi.allowInsecureAuth: true + restart
Likely related
This appears to be a variant of #16820 / #17127 / #17681 where the probe/status client connection path doesn't present or negotiate operator scopes, even when credentials are available. The fixes in those PRs covered webchat and allowInsecureAuth but not the CLI probe/status path.
OpenClaw version
2026.3.13 (61d171a)
Operating system
macOS 26.3.1 (arm64)
Install method
pnpm
Impact and severity
Cosmetic — openclaw status still returns all useful operational data (agents, sessions, channels, security audit) via direct file/process reads. Only the gateway self-reported status row is affected. No impact on crons, agents, or Telegram.
Summary
openclaw statusandgateway probereportmissing scope: operator.readon a loopback gateway with token auth mode, even thoughgateway call --token <token>works correctly. The probe/status client path doesn't negotiate operator scopes properly.Steps to reproduce
auth.mode: "token"and a token inopenclaw.jsonbind: "loopback", port 18789)openclaw status→ Gateway row showsunreachable (missing scope: operator.read)openclaw gateway probe --token <token>→ samemissing scope: operator.readopenclaw gateway call status --token <token>→ works fine, returns full status JSONExpected behavior
openclaw statusshould read the gateway token from config and connect withoperator.readscope. At minimum,gateway probe --token <token>should work when the token is passed explicitly.Actual behavior
openclaw status: no--tokenoption, doesn't read token from config for scope negotiationgateway probe --token <token>: accepts the flag but still fails withmissing scope: operator.readgateway call status --token <token>: works correctlyGateway logs confirm the scope error on every status/system-presence/config.get RPC:
Workarounds attempted (none resolved it)
openclaw gateway install --force+ restartOPENCLAW_GATEWAY_TOKENenv vargateway probe --token <token>gateway.controlUi.allowInsecureAuth: true+ restartLikely related
This appears to be a variant of #16820 / #17127 / #17681 where the probe/status client connection path doesn't present or negotiate operator scopes, even when credentials are available. The fixes in those PRs covered webchat and
allowInsecureAuthbut not the CLI probe/status path.OpenClaw version
2026.3.13 (61d171a)
Operating system
macOS 26.3.1 (arm64)
Install method
pnpm
Impact and severity
Cosmetic —
openclaw statusstill returns all useful operational data (agents, sessions, channels, security audit) via direct file/process reads. Only the gateway self-reported status row is affected. No impact on crons, agents, or Telegram.