Fix: missing scope: operator.read Despite Valid On-Disk Operator Token

Problem

openclaw gateway probe and openclaw status --all report missing scope: operator.read even though:

• ~/.openclaw/identity/device-auth.json contains a valid operator token with operator.read
• openclaw devices list confirms the local paired device has role operator with operator.read
• Token rotation via openclaw devices rotate succeeds and returns a fresh token including operator.read

The scope exists on disk and in device state, but the local control-plane probe path does not honour it.

openclaw gateway probe  →  Connect OK, RPC limited / missing scope: operator.read
openclaw status --all   →  Gateway unreachable / missing scope: operator.read

Diagnostic Steps

Step 1: Confirm which token the gateway is actually using

# Check what identity the runtime is loading
openclaw gateway inspect --auth
# or
openclaw debug identity --verbose

Compare the token source and scopes reported here against device-auth.json.

Step 2: Check for stale in-memory token

# Full stop — not just restart
openclaw gateway stop
sleep 3
openclaw gateway start

# Re-probe immediately
openclaw gateway probe

If the error clears after a clean stop/start (not just restart), the gateway was holding a stale in-memory token.

Step 3: Verify the token path the probe command resolves

cat ~/.openclaw/identity/device-auth.json | jq '.operator.scopes'
# Should include "operator.read"

# Check if there is a secondary credential file being loaded instead
ls -la ~/.openclaw/identity/
ls -la ~/.openclaw/auth/

Look for any additional token files that may shadow device-auth.json.

Fix

Option 1: Force token reload after rotation (Recommended)

After rotating the token, explicitly tell the gateway to reload its auth state:

openclaw devices rotate --device <id> --role operator --scope operator.admin,operator.approvals,operator.pairing,operator.read,operator.write

# Force reload — do not use 'restart' as it may preserve in-memory state
openclaw gateway stop
sleep 2
openclaw gateway start

openclaw gateway probe

Option 2: Re-pair the local device

If the runtime is resolving a different identity source, re-pairing forces a clean credential write:

# Remove stale identity files
rm ~/.openclaw/identity/device.json
rm ~/.openclaw/identity/device-auth.json

# Re-pair
openclaw devices pair --role operator

# Restart gateway
openclaw gateway stop && openclaw gateway start

# Verify
openclaw gateway probe
openclaw status --all

Option 3: Explicitly set the operator token path in config

If the gateway is loading from a non-default path, pin it explicitly in openclaw.json:

{
  "gateway": {
    "auth": {
      "tokenPath": "~/.openclaw/identity/device-auth.json"
    }
  }
}

Then restart:

openclaw gateway stop && openclaw gateway start
openclaw gateway probe

Option 4: Disable and re-enable Tailscale serve

Given the Tailscale serve + loopback + token auth combination, the auth path may be resolving through the Tailscale interface incorrectly:

tailscale serve reset
openclaw gateway stop
openclaw gateway start
tailscale serve https / http://127.0.0.1:18789
openclaw gateway probe

Verification

A successful fix should produce:

$ openclaw gateway probe
✓ Connect OK
✓ RPC OK
✓ Scopes: operator.read, operator.write, operator.admin

$ openclaw status --all
✓ Gateway reachable
✓ Auth: operator token valid

Workaround

Core functionality (Telegram, chat) is unaffected. If the above options do not resolve the probe error, the control-plane status check can be bypassed for now:

# Use direct RPC instead of probe
openclaw gateway rpc --method status

Environment

Upstream Fix Required

The local control-plane auth path in gateway probe / status --all should:

1. Always resolve from device-auth.json as the authoritative token source for loopback + token auth mode
2. Reload token state after rotation without requiring a full gateway stop/start
3. Log the resolved token source and scopes at startup to make auth-path mismatches immediately visible

Likely regression introduced in 2026.3.13 alongside Tailscale serve integration changes. Request comparison with auth resolution behaviour in 2026.3.11.