Bug type

Behavior bug (incorrect output/state without crash)

Summary

Summary

openclaw status and openclaw status --all report the gateway as "unreachable (missing scope: operator.read)" even though the CLI's device identity has full operator scopes (including operator.read and operator.write).

Environment

• OpenClaw: 2026.3.13
• OS: macOS 15.7.4 (x64) — Intel MacBook Pro
• Node: 22.22.0
• Install method: npm (global)
• Gateway: LaunchAgent, loopback bind, Tailscale Serve

Steps to reproduce

1. Fresh update to 2026.3.13 via npm update -g openclaw
2. openclaw doctor --fix (repaired LaunchAgent entrypoint after update)
3. openclaw gateway restart
4. openclaw status --all

Expected behavior

Gateway should show as reachable with full status details, since the CLI device has operator.read scope.

Actual behavior

Overview table shows:

Steps to reproduce

1. Fresh update to 2026.3.13 via npm update -g openclaw
2. openclaw doctor --fix (repaired LaunchAgent entrypoint after update)
3. openclaw gateway restart
4. openclaw status --all

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

Further investigation:

• openclaw gateway probe confirms: "Connect: ok · RPC: limited - missing scope: operator.read"
• Device identity (~/.openclaw/identity/device.json) device ID: 37546cf3...
• openclaw devices list confirms this device has full scopes: operator.admin, operator.approvals, operator.pairing, operator.write, operator.read
• All actual operations work correctly (Telegram, agents, memory, hooks)

Expected behavior

openclaw status --all should show the gateway as reachable with full status details, since the CLI's device identity has operator.read scope confirmed via openclaw devices list.

Actual behavior

Gateway overview row shows:
Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (missing scope: operator.read)

Gateway logs confirm the WebSocket probe connects but requests are 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

The status command's WebSocket probe appears to not send the device token/identity during the handshake, so the gateway treats it as unprivileged despite the device having full scopes.

OpenClaw version

2026.3.13

Operating system

macOS 15.7.4 (x64)

Install method

npm (global)

Model

gpt-5.4 (OpenAI Codex)

Provider / routing chain

openai-codex/gpt-5.4

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

`openclaw status --all` output (relevant rows):

Update          │ pnpm · npm latest 2026.3.13
Gateway         │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (missing scope: operator.read)
Gateway service │ LaunchAgent installed · loaded · running (pid 41192)

`openclaw gateway probe` output:

Reachable: yes
Probe budget: 3000ms
Warning:
- Probe diagnostics are limited by gateway scopes (missing operator.read).
  Hint: pair device identity or use credentials with operator.read.
Local loopback ws://127.0.0.1:18789
  Connect: ok (16ms) · RPC: limited - missing scope: operator.read

`openclaw devices list` shows the CLI device (37546cf3...) has full scopes:
  operator.admin, operator.approvals, operator.pairing, operator.write, operator.read

Gateway stderr logs:

[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

Note: `openclaw status` also reports install method as "pnpm" when the package was
installed via npm. This appears to come from reading the `packageManager` field in
OpenClaw's own package.json rather than detecting the actual install method.

Impact and severity

• Affected: Any user running openclaw status on the same machine as the gateway
• Severity: Annoying — no workflow is blocked, all operations work correctly
• Frequency: Always — reproduces on every openclaw status and openclaw status --all call
• Consequence: Misleading diagnostic output causes unnecessary investigation. AI agents that read status output (e.g., for automated security audits) interpret "unreachable" as a real problem and waste operator time troubleshooting a non-issue. The false "pnpm" install method report also causes AI agents to suggest wrong update commands.

Additional information

• Last known good version: Unknown — this may have existed before 2026.3.13 but was first investigated on this version after updating from 2026.3.11.
• Environment: macOS 15.7.4 (x64), Intel MacBook Pro 2018, Node 22.22.0, gateway running as LaunchAgent with loopback bind and Tailscale Serve.
• The "Regression" bug type was selected as the closest match, but this may be a long-standing behavior bug rather than a true regression.