Summary

The OpenClaw CLI is in a scope deadlock: the current paired CLI has only operator.read, the gateway keeps auto-reissuing a pending repair request for the full default operator bundle, and device.pair.approve / device.pair.reject both require scope the CLI does not have. There is no other paired device with admin-level scope available as a bootstrap path.

Environment

• Platform: darwin
• Client: cli (mode probe for paired entry, mode cli for pending request)
• Gateway: ws://127.0.0.1:18789, loopback bind
• Config: /Users/<redacted>/.openclaw/openclaw.json

What happened

• Current paired CLI device is valid with scope operator.read only.
• A pending repair request keeps appearing for the same CLI device, asking for the full default operator bundle: operator.admin, operator.read, operator.write, operator.approvals, operator.pairing, operator.talk.secrets.
• The pending request auto-reissues every few minutes (TTL ≈ 5 min based on PENDING_TTL_MS), so request IDs rotate.
• Any gateway control-plane call above operator.read fails with gateway closed (1008): pairing required. This includes cron management and ACP / sub-agent spawn.
• openclaw devices reject <id> itself fails with the same pairing required error, because device.pair.reject requires operator.pairing scope per the gateway method-scope map.

What I expected

One of:

• A way to reject or downgrade the repair request from the current paired CLI without already having operator.pairing.
• A supported bootstrap flow to request only the minimal scopes actually needed (e.g. operator.read + operator.admin for cron).
• A documented recovery path for this situation that does not require the very scope needed to approve or reject the repair.

What I verified

• Current paired CLI has only operator.read (confirmed in openclaw devices list --json and locally in ~/.openclaw/devices/paired.json).
• Pending request asks for the full bundle (confirmed in openclaw devices list --json and in ~/.openclaw/devices/pending.json).
• No other paired devices with admin-level scope exist.
• I did not edit local JSON manually to avoid corrupting paired state.
• I did not restart the gateway, since the deadlock is at the scope layer, not at the gateway lifecycle.

What is blocked

• cron management through the gateway.
• ACP / sub-agent spawn through the gateway.
• Any other gateway control-plane action requiring scope above operator.read.

Likely root cause (from reading the codebase)

The CLI default scope set appears to be hardcoded as CLI_DEFAULT_OPERATOR_SCOPES = [admin, read, write, approvals, pairing, talk.secrets]. Combined with the fact that approve/reject themselves require operator.pairing, a CLI that ends up in operator.read cannot self-service its way out without an external bootstrap path.

Questions

1. Is there a supported way to create a minimal-scope CLI repair / pairing request (for example only operator.read + operator.admin)?
2. If not, what is the intended bootstrap or recovery flow for a CLI stuck at operator.read with an auto-reissued over-scoped repair request?
3. Is there a way to override CLI_DEFAULT_OPERATOR_SCOPES in config for repair requests?

I can provide full CLI outputs and local JSON dumps on request, with secrets / device IDs redacted.

Thanks.