Bug type

Behavior bug (incorrect output/state without crash)

Summary

On a local loopback gateway using token auth, openclaw status and openclaw gateway probe report degraded diagnostics with:

• missing scope: operator.read

even though the paired local CLI device has an operator token that includes operator.read.

Steps to reproduce

1. Run OpenClaw locally with loopback gateway + token auth.
2. Pair the local CLI as an operator device.
3. Verify/rotate the operator device token so it includes:

• operator.admin
• operator.approvals
• operator.pairing
• operator.read
• operator.write

4. Run:

openclaw gateway probe --json
openclaw status

Actual
gateway probe --json reports:

{
"connect": {
"ok": true,
"rpcOk": false,
"scopeLimited": true,
"error": "missing scope: operator.read"
}
}

openclaw status also reports degraded reachability / missing operator.read.

Expected behavior

If the paired local CLI device has a valid operator token with operator.read, then openclaw status and openclaw gateway probe should use that capability for operator-read RPCs and not remain scope-limited.

Actual behavior

• openclaw devices list shows the paired operator device with operator.read
• rotating the device token succeeds
• ~/.openclaw/devices/paired.json shows the cached operator token now includes operator.read
• no OPENCLAW_GATEWAY_TOKEN env var is set in a clean shell
• openclaw gateway status reports the gateway itself is healthy

OpenClaw version

OpenClaw 2026.3.13 (61d171a)

Operating system

Linux 6.8.0-101-generic (x64)

Install method

npm global

Model

gpt-5.4

Provider / routing chain

• Provider/routing: local CLI → loopback token-auth gateway (127.0.0.1:18789) with paired operator device present

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Low runtime impact, but confusing diagnostics:

• gateway is healthy
• pairing is healthy
• device token is correctly scoped
• status/probe still appear degraded

Additional information

It looks like the CLI is connecting via the shared gateway.auth.token path first and not preferring/upgrading to the paired device token for operator-read RPCs after connect succeeds.