Environment

• OpenClaw version: 2026.3.13
• OS: macOS 26.3.1 (arm64)
• Gateway mode: local
• Gateway service: LaunchAgent running
• Channel: Telegram enabled and working

Problem

After upgrading to OpenClaw 2026.3.13, the following commands report that the Gateway is reachable but RPC is limited because of a missing scope:

• openclaw status
• openclaw gateway probe

Typical output:

missing scope: operator.read

However, the paired CLI device token already includes operator.read.

This makes it look like the CLI is not actually using the paired CLI device token for these RPC calls, or is preferring another auth path with reduced scopes.

Symptoms

openclaw status

Shows something like:

Gateway ... unreachable (missing scope: operator.read)

openclaw gateway probe

Shows something like:

Connect: ok
RPC: limited - missing scope: operator.read

What still works

• Gateway service is running
• Telegram channel works normally
• Sessions work
• Security audit is clean
• CLI can connect to the gateway
• The issue appears limited to status/probe diagnostic RPC scope resolution

Evidence

openclaw devices list --json

The CLI device shows full operator scopes, including operator.read.

Example:

{
  "clientId": "cli",
  "clientMode": "cli",
  "role": "operator",
  "scopes": [
    "operator.read",
    "operator.admin",
    "operator.write",
    "operator.approvals",
    "operator.pairing"
  ],
  "tokens": [
    {
      "role": "operator",
      "scopes": [
        "operator.admin",
        "operator.approvals",
        "operator.pairing",
        "operator.read",
        "operator.write"
      ]
    }
  ]
}

Despite this, status and gateway probe still report missing operator.read.

Gateway logs

Gateway logs show RPC failures like:

errorCode=INVALID_REQUEST
errorMessage=missing scope: operator.read

Affected RPCs include:

• status
• system-presence
• config.get

This suggests that the CLI connection succeeds, but the RPC auth context is using a credential source that does not include operator.read.

Troubleshooting already attempted

I already tried all of the following and the issue still persists:

1. Upgraded to 2026.3.13
2. Ran openclaw doctor and accepted the gateway service entrypoint fix (entry.js → index.js)
3. Rotated the CLI device token
4. Removed and recreated the CLI device
5. Deleted local identity cache files:
   • ~/.openclaw/identity/device.json
   • ~/.openclaw/identity/device-auth.json
6. Restarted the gateway
7. Opened a fresh terminal and retried
8. Replaced gateway.auth.token with a newly generated token
9. Re-ran openclaw doctor

The paired CLI device still ends up having full scopes in devices list --json, but status / gateway probe still fail with missing operator.read.

Additional observations

There are also operator devices for webchat / control-ui that only have partial scopes:

• operator.admin
• operator.approvals
• operator.pairing

But even after isolating and repairing the CLI device, the problem still persists.

This suggests one of the following:

1. CLI status/probe is not actually using the paired CLI device token
2. CLI prefers gateway.auth.token over device token and that path lacks operator.read
3. There is a regression in 2026.3.13 around local gateway auth scope resolution

Expected behavior

If the CLI device token includes operator.read, then:

• openclaw status
• openclaw gateway probe

should return full normal output, rather than reporting:

missing scope: operator.read

Actual behavior

The Gateway connection succeeds, but RPC calls are restricted due to:

missing scope: operator.read

Severity

This does not appear to break core runtime behavior:

• Gateway works
• Telegram works
• Sessions work

So this seems like a diagnostic/auth scope bug rather than a total service failure.