openclaw - 💡(How to fix) Fix CLI re-pair after self-removal races pending request rotation and falls into stale fallback

Summary

When I intentionally revoke/remove the only paired CLI device and then try to re-approve it, openclaw devices approve becomes unstable because the pending requestId churns faster than the CLI fallback can act on it. In practice, the CLI reports unknown requestId while the pending request keeps being re-issued.

There also seems to be an auth-path mismatch around device-token management:

• openclaw devices revoke --device <id> --role operator was denied with caller-missing-scope scope=operator.admin
• openclaw devices remove <deviceId> --url ws://127.0.0.1:18789 --token <shared-token> succeeded
• after removal, openclaw devices approve <requestId> via CLI could not catch the rotating pending request reliably

This looks adjacent to #74484, but the failure here is specifically around re-approval after self-removal / revocation, plus the CLI fallback repeatedly losing the current pending request.

Environment

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

Repro

1. Start with a paired CLI device.
2. Attempt to revoke the operator token:
   • openclaw devices revoke --device <deviceId> --role operator --json
3. Observe Gateway denial:
   • device token revocation denied
   • gateway log: reason=caller-missing-scope scope=operator.admin
4. Remove the paired device entry instead using explicit shared-token auth:
   • openclaw devices remove <deviceId> --url ws://127.0.0.1:18789 --token <shared-token> --json
5. Confirm the CLI is now unpaired and the gateway starts returning pairing required with a pending requestId.
6. Try to approve the pending request:
   • openclaw devices list
   • openclaw devices approve <requestId>
7. Observe that the request id rotates/reissues during CLI fallback, and approval often ends with:
   • unknown requestId
   • or a newer pairing required (requestId: ...)

What I expected

One of these should work reliably:

• explicit shared-token auth (--url ... --token ...) should approve the currently pending request without falling into a stale local fallback path, or
• the CLI should pin the current pending request during fallback so devices approve <requestId> does not race the auto-reissued request, or
• there should be a documented recovery flow for "I removed the only paired device and want to re-pair it immediately".

What happened

• direct revoke failed with caller-missing-scope scope=operator.admin
• explicit shared-token devices remove worked
• immediate re-approval via CLI was flaky because pending requestIds kept changing
• local fallback surfaced unknown requestId even though devices list still showed a current pending request for the same device

Notes

I was eventually able to recover only by approving the pending request directly against the local pairing store instead of relying on the normal CLI path.

The resulting re-pair was also narrower than the original one (operator.pairing, operator.read only), so this flow currently risks accidental scope downgrade during recovery.

Why this matters

This makes self-service session recovery brittle when there is only one CLI device available. A user can successfully remove the paired device but then be unable to re-approve it through the supported CLI path because request IDs churn underneath the fallback behavior.

Related

• Related but not identical: #74484