openclaw - 💡(How to fix) Fix Explicit --url/--token device management auth path appears to leak paired-device state

Summary

When openclaw devices commands are invoked with explicit shared-token auth (--url ... --token ...), the control path still appears to behave like a paired-device session in some cases.

In particular, device-token management during recovery can fail with scope errors that look tied to the currently paired device token rather than the explicitly supplied shared gateway token.

This makes the auth model hard to reason about and breaks expected recovery flows.

Environment

• Platform: macOS arm64
• OpenClaw: 2026.5.7
• Gateway: local loopback (ws://127.0.0.1:18789)
• Auth mode: gateway.auth.mode = token
• Client: cli

Repro

1. Start from a normally paired CLI device.
2. Run device-token revocation:
   • openclaw devices revoke --device <deviceId> --role operator --json
3. Observe denial from the gateway:
   • device token revocation denied
   • gateway log: reason=caller-missing-scope scope=operator.admin
4. Retry recovery-oriented commands with explicit shared-token auth:
   • openclaw devices remove <deviceId> --url ws://127.0.0.1:18789 --token <shared-token> --json
   • openclaw devices approve <requestId> --url ws://127.0.0.1:18789 --token <shared-token>
5. Observe that explicit auth does not lead to a clean, obviously shared-token-only control path:
   • remove succeeds
   • approve falls back into pairing required / rotating request-id behavior instead of just approving with the provided token

What I expected

If I explicitly provide --url and a valid shared gateway token:

• the CLI should authenticate only through that shared token
• device-management authz should be evaluated against the shared-token scopes
• paired-device token state should not override or silently interfere with the request
• devices approve / devices revoke should not unexpectedly degrade into a paired-device recovery path

What happened

The observed behavior suggests the explicit shared-token auth path is not consistently isolated from device-token state:

• devices revoke was denied with caller-missing-scope scope=operator.admin
• devices remove succeeded with the same explicit shared-token auth pattern
• devices approve did not behave like a straightforward shared-token approval path and instead hit pairing required behavior

That asymmetry makes it look like some commands still inherit or get confused by the local paired-device session even when explicit token auth was requested.

Why this matters

The docs say that when --url is set, the CLI should not fall back to config/environment credentials and explicit auth must be passed. That implies a predictable auth path.

Right now, recovery/debugging is much harder because explicit shared-token auth does not appear to guarantee a clean separation from local paired-device state.

Related

• #83356 — request-id churn / stale fallback during immediate re-pair after self-removal
• #74484 — related pairing deadlock around CLI scope recovery