openclaw - 💡(How to fix) Fix [Bug]: Regression of #78727 — TUI scope-upgrade retry generates churning requestIds, blocks manual approval on 2026.5.12

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

End-user repro of the "each subsequent CLI invocation generates a fresh pending request that supersedes any previously-approved one" behavior described in #78727 (closed 2026-05-11). Filing as a new issue because #78727 is locked; reproducible on 2026.5.12 (f066dd2) via the embedded TUI path (not just openclaw mcp serve).

Steps to reproduce

1. Fresh install: npm i -g openclaw@latest.
2. openclaw onboard → complete pairing as operator. Initial scopes settle at operator.read + operator.pairing.
3. openclaw chat → send a prompt that requires a shell tool (e.g. "list files in ~/Downloads").
4. Agent immediately requests scope upgrade to operator.write. Gateway logs:

security audit: device access upgrade requested reason=scope-upgrade
  roleFrom=operator roleTo=operator
  scopesFrom=operator.read scopesTo=operator.write
GatewayClientRequestError: scope upgrade pending approval (requestId: <UUID-A>)
EMBEDDED FALLBACK: Gateway agent failed; running embedded agent:
  GatewayTransportError: gateway closed (1008): pairing required:
  device is asking for more scopes than currently approved

1. TUI silently retries. Each retry generates a new requestId. openclaw devices list shows only ONE row in the pending table at any moment, but the id rotates roughly every ~1s.
2. From a second shell, attempting openclaw devices approve <id-from-list> almost always returns unknown requestId — the id is already stale by the time the approve call arrives.
3. openclaw devices approve --latest only previews the current request (prints "Approve this exact request with: openclaw devices approve <ID>") — it does not auto-approve, which adds another race window even after the user reads the id.

Expected behavior

Per #78727's accepted scope: scope upgrades should not generate a flood of superseding requestIds that prevent a user from approving any single one. Either the TUI retry should back off while a pending scope upgrade exists, or --latest should support atomic one-shot approval.

Actual behavior

• TUI retries fast enough to invalidate every requestId before a human can read + type the approve command.
• --latest flag is preview-only; no --confirm option exists to make it atomic.
• The only working workaround is a tight shell-side loop polling list + approve, which has its own unintended side-effects (filing a separate private security report on those).

OpenClaw version

2026.5.12 (f066dd2)

Operating system

macOS 15.x (Darwin 25.4.0)

Install method

npm i -g openclaw@latest (prefix ~/.npm-global)

Model

google/gemini-2.5-flash (google:manual auth profile)

Provider / routing chain

openclaw embedded → google/gemini-2.5-flash (Gemini API direct)

Additional provider/model setup details

Agent invoked a shell tool to satisfy a user prompt. Scope upgrade pre-empts the tool call. Same behavior was observed earlier in the session under anthropic/claude-sonnet-4-6 before switching providers, so the issue does not appear model-specific.

Logs, screenshots, and evidence

See gateway log excerpt in Steps to reproduce above. Full unfiltered openclaw logs --plain --limit 250 available on request; relevant events repeat across multiple embedded_run_agent_end / embedded_run_failover_decision cycles with failoverReason="billing" (misleading label) and pairing-required cause.

Impact and severity

Medium-high UX impact. Out-of-the-box first user who tries any tool-using prompt cannot escape the loop without either:

• discovering the tight-loop workaround from the failure logs, or
• killing the TUI process to let the requestId stabilize before approving manually.

Suggested fix

1. TUI retry backoff when failure reason is pairing-required: scope-upgrade (freeze retry until pending resolves or N seconds pass).
2. --latest --confirm (or --latest --approve) flag on openclaw devices approve for atomic one-shot approval of whatever's currently pending. Today the name --latest is misleading because it only previews.

Related

• Regression / unfinished follow-up of #78727 (closed 2026-05-11, locked).
• A separate private security advisory has been filed on a side-effect of the shell-loop workaround.