Best possible solution:

Keep the existing approval refresh helper as the owner, but invoke it from reconnect with an active-client guard and add redacted real behavior proof for the Control UI reconnect flow.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible but not live-run: current main's hello path applies the snapshot and handles approval events, while the approval-list RPC handlers exist separately and are not called during reconnect.

Is this the best way to solve the issue?

No as submitted. Calling the existing approval refresh helper on hello is the right boundary, but the PR needs an active-client guard before applying refreshed state.

Full review comments:

• [P2] Guard approval refreshes against stale reconnect clients — ui/src/ui/app-gateway.ts:849
  The new fire-and-forget refresh captures the current state.client, awaits the approval-list RPCs, and then writes state.execApprovalQueue. If another reconnect or gateway URL change replaces host.client before those RPCs settle, the older client can overwrite the new connection's approval queue; the neighboring reconnect work guards this by checking host.client !== client before async mutations, so this refresh needs the same protection before applying results.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against aa91c9d4a950.

Label justifications:

• P2: This is a normal-priority Control UI approval bug fix with limited blast radius, but it affects whether pending approvals reappear after reconnect.
• merge-risk: 🚨 session-state: The patch can stale or mis-associate the Control UI approval queue if an older reconnect refresh finishes after a newer client becomes active.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR only lists tests and git diff --check; it needs redacted after-fix proof such as a short Control UI reconnect recording, terminal/browser output, or logs showing pending exec/plugin approvals reappear, and updating the PR body should trigger a fresh ClawSweeper review or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Source +2, Tests +49. Total +51 across 4 files.

What I checked:

• Current reconnect path: On current main, connectGateway handles onHello, applies the hello snapshot, processes pending aborts, and continues into reconnect startup work without refreshing pending approval lists. (ui/src/ui/app-gateway.ts:807, aa91c9d4a950)
• Approval refresh helper mutates after async RPCs: refreshPendingApprovalQueue captures state.client, awaits both approval-list RPCs, then assigns state.execApprovalQueue; it has no active-client check before applying the result. (ui/src/ui/controllers/exec-approval.ts:327, aa91c9d4a950)
• Sibling reconnect work guards active client: Nearby reconnect startup work passes the expected client into loadAgentsThenRefreshActiveTabForClient and deferred startup work returns when host.client !== client, showing the local invariant this new async refresh should preserve. (ui/src/ui/app-gateway.ts:753, aa91c9d4a950)
• Linked issue context: The linked issue reports that server-side exec.approval.list and plugin.approval.list still expose pending approvals after disconnect, but Control UI does not reload them after a fresh hello.
• PR diff: The patch adds void refreshPendingApprovalQueue(host) directly inside the hello handler and adds a reconnect hydration test for both exec and plugin approvals. (ui/src/ui/app-gateway.ts:849, 4c74aa6301a5)
• Proof gate: The PR body lists focused Vitest and git diff --check commands, but no screenshot, recording, terminal output, live log, or linked artifact demonstrating the after-fix Control UI reconnect behavior; the Real behavior proof check is failing. (4c74aa6301a5)

Likely related people:

• RomneyDa: Recent merged work in https://github.com/openclaw/openclaw/pull/98146 introduced or carried forward the current Control UI reconnect handler and approval refresh helper touched by this PR. (role: recent area contributor; confidence: high; commits: 9003042c5fa0; files: ui/src/ui/app-gateway.ts, ui/src/ui/controllers/exec-approval.ts, ui/src/ui/app.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.