openclaw - 💡(How to fix) Fix TUI / gateway-client connects but RPC calls fail with `missing scope: operator.read` despite paired device/token showing full operator scopes [3 comments, 4 participants]

Summary

On a fresh local macOS install of OpenClaw, the TUI / gateway-client can connect to the local gateway, but scope-gated RPC calls fail with:

• missing scope: operator.read

This happens even after:

• fresh device auth reset
• device token rotation with full operator scopes
• removing + re-pairing the local device
• clean gateway restart
• explicit --token TUI launch

The on-disk pairing/token state shows the correct scopes, but runtime RPC auth still behaves as if operator.read is missing.

Environment

• OpenClaw version: 2026.3.13
• OS: macOS 15.7.4 arm64
• Node: 25.8.1
• Gateway mode: local loopback
• Gateway auth: token
• Channel tested: local TUI (openclaw-tui, gateway-client)

Expected behavior

A locally paired/operator-scoped TUI client should be able to call scope-gated RPCs such as:

• status
• system-presence
• config.get

Actual behavior

Connection succeeds, but RPC calls fail with:

• INVALID_REQUEST
• missing scope: operator.read

openclaw gateway probe reports:

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

openclaw status --all reports:

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

Reproduction / troubleshooting already tried

Initial symptom

The gateway was running and healthy, but:

• openclaw gateway probe
• openclaw status --all

both reported missing scope: operator.read.

Device/pairing inspection

Local files showed device auth + pairing state, including:

• ~/.openclaw/identity/device-auth.json
• ~/.openclaw/devices/paired.json

At one point there was a mismatch where:

• paired device scopes included operator.read
• stored operator token scopes only showed operator.admin

Remediation steps attempted

1. Rotated device token with explicit scopes:

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

2. Verified token rotation succeeded.

3. Updated local device auth state.

4. Removed paired device and re-paired it.

5. Restarted gateway cleanly:

   openclaw gateway restart

6. Removed local device auth file entirely and let it regenerate:

   • backed up + removed ~/.openclaw/identity/device-auth.json
   • removed paired device
   • allowed fresh auto-pair on reconnect

7. Launched TUI with explicit gateway token:

   TOKEN=$(python3 - <<'PY'
   import json, os
   p=os.path.expanduser("~/.openclaw/openclaw.json")
   with open(p) as f:
       print(json.load(f)["gateway"]["auth"]["token"])
   PY
   )
   openclaw tui --url ws://127.0.0.1:18789 --token "$TOKEN"

Observations

Freshly recreated local device auth shows full scopes

device-auth.json was recreated with operator scopes including:

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

Paired device table also shows full scopes

openclaw devices list --json shows the paired device with:

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

But runtime still rejects RPCs

Gateway logs continue to show:

• status -> missing scope: operator.read
• system-presence -> missing scope: operator.read
• config.get -> missing scope: operator.read

Additional clue

One explicit-token TUI attempt produced:

• unauthorized: gateway token mismatch

But after correcting token launch, successful connections still failed with missing scope: operator.read, so token mismatch does not fully explain the problem.

Relevant log snippets

Examples seen in gateway 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

Earlier clue:

[gateway] security audit: device access upgrade requested reason=scope-upgrade ... scopesFrom=operator.read scopesTo=operator.admin client=gateway-client

And one token issue:

[ws] unauthorized ... client=openclaw-tui ui v2026.3.13 reason=token_mismatch

Suspected issue

This looks like a runtime auth/path mismatch or caching bug where:

• device/token/pairing state on disk is correct,
• but the active TUI/gateway-client session is authorized with an unexpected or stale effective scope set.

Possibly related to:

• client identity differences (gateway-client / openclaw-tui vs cli)
• token/device scope reconciliation
• stale effective scopes after rotation/re-pair
• auth path differences between implicit local device auth and explicit --token TUI connections