Bug type

Regression (worked before, now fails)

Summary

openclaw status always reports "unreachable (missing scope: operator.read)" even when the gateway is healthy, agents are responding, and a fully-scoped paired CLI device identity exists. The internal WS client used by openclaw status authenticates via the shared-token path and does not perform the device-auth v2 challenge-response handshake. Since the 2026.3.12 security fix (GHSA-rqpp-rjj8-7wv8) clears self-declared scopes on shared-token connects, the status client's connection is always stripped of operator.read. Other CLI paths that use device-auth (TUI, Control UI webchat) or RPC-level token auth (openclaw gateway call status) work correctly. openclaw gateway probe has the same issue.

Steps to reproduce

1. Fresh install, 2026.3.13, gateway running as systemd user service, auth.mode=token, bind=loopback
2. Confirm gateway is healthy: openclaw gateway health → OK
3. Confirm RPC works: openclaw gateway call status → returns full status JSON
4. Confirm device identity exists with operator.read scope in both ~/.openclaw/identity/device-auth.json and gateway-side paired devices list
5. Run openclaw status
6. Gateway row shows: "unreachable (missing scope: operator.read)"
7. Gateway log confirms the status WS client connected but RPCs were rejected:
   [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

Attempted workarounds (all failed):

• Set/unset OPENCLAW_GATEWAY_TOKEN env var
• Delete and re-pair device identity (fresh v2 keypair, all operator scopes approved)
• Rotate device token with explicit --scope flags
• Switch gateway.auth.mode to "none" (error changes to "connect failed: device identity")
• openclaw doctor --fix (restarts gateway, doesn't fix auth path)

Expected behavior

openclaw status should use device-auth v2 when a valid identity exists at ~/.openclaw/identity/, performing the challenge-response handshake to obtain scoped access — consistent with how the TUI and Control UI connect. Alternatively, operator scopes should be preserved for local loopback shared-token connects (the intent of the 2026.2.26 fix in PR #27498).

Actual behavior

openclaw status connects using the shared token path (connect.params.auth.token) without including a device block (id/publicKey/signature). The 2026.3.12 security fix (GHSA-rqpp-rjj8-7wv8) strips scopes from this connection. All subsequent RPCs requiring operator.read are rejected. The gateway probe also fails for the same reason.

The 2026.2.26 fix "Gateway shared-auth scopes: preserve requested operator scopes for shared-token clients when device identity is unavailable" (PR #27498) appears to have been regressed by the 3.12 security patch. The 2026.3.13 fix "restore the operator-only device-auth bypass" (#45512) fixed the Control UI path but not the CLI status path.

OpenClaw version

2026.3.13 (61d171a)

Operating system

Ubuntu 24, Linux 6.17.0-19-generic (x64), Node 24.14.0

Install method

No response

Model

N/A — issue is in CLI/gateway auth, not model-dependent

Provider / routing chain

Local gateway, systemd user service, bind=loopback, auth.mode=token. DeepSeek as primary model but irrelevant to the bug — the issue is in the openclaw status WS client auth path before any model interaction occurs.

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response