Best possible solution:

Land a narrow Control UI fix that keeps the reused approval modal visible for queued approvals and uses the existing approval-list refresh path, after real browser proof is attached.

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

Yes, source inspection gives a medium-confidence reproduction for the modal reuse subcase: current main can keep the same custom element mounted while its internal opened flag prevents reopening a closed underlying dialog. I did not run a browser repro for the full click path, so real behavior proof is still needed.

Is this the best way to solve the issue?

Yes, the proposed shape is the best observed boundary: the shared modal primitive owns reopening a reused dialog, and the gateway hello change reuses the existing approval queue refresh helper. The remaining gap is proof, not an alternate implementation path.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add status: 🛠️ actively grinding: The PR author has acted after the latest ClawSweeper review and work remains. Needs real behavior proof before merge: The PR body lists unit tests and build commands only; it needs redacted real Control UI proof such as a screenshot, recording, live output, or logs showing the next queued approval remains visible after resolving the active one. 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.
• remove status: 📣 needs proof: Current PR status label is status: 🛠️ actively grinding.

Label justifications:

• P2: This is a normal-priority Control UI workflow bug fix for hidden pending approvals with limited blast radius.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 🛠️ actively grinding: The PR author has acted after the latest ClawSweeper review and work remains. Needs real behavior proof before merge: The PR body lists unit tests and build commands only; it needs redacted real Control UI proof such as a screenshot, recording, live output, or logs showing the next queued approval remains visible after resolving the active one. 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 +7, Tests +103. Total +110 across 6 files.

What I checked:

• Current modal behavior: Current main opens the native dialog only from firstUpdated(), and openDialog returns forever once the component's internal opened flag is set, even if the underlying dialog was later closed while the custom element instance stays mounted. (ui/src/ui/components/modal-dialog.ts:90, 21d1e1f0fc9d)
• Current approval prompt reuse surface: The approval prompt renders a stable openclaw-modal-dialog for the active queue item, so moving from one queued approval to the next can reuse the same custom element instance. (ui/src/ui/views/exec-approval.ts:161, 21d1e1f0fc9d)
• Shared approval refresh path: refreshPendingApprovalQueue already lists both exec and plugin approvals and merges refreshed state with approvals that arrive during the refresh, making it the right existing helper for reconnect hydration. (ui/src/ui/controllers/exec-approval.ts:327, 21d1e1f0fc9d)
• PR implementation: The PR adds updated() reopening to the modal, imports refreshPendingApprovalQueue into connectGateway(), calls it on hello, and adds regression tests for modal reuse, queued approval state, plugin approvals, and hello-list hydration. (ui/src/ui/components/modal-dialog.ts:94, ef98bd1959a7)
• Linked bug and candidate fix: The PR has a closing reference to the open bug report, whose body describes two queued Control UI approvals, resolving one, and the next approval becoming hidden while still pending.
• Real behavior proof gap: The PR body lists unit/node tests, git diff --check, and ui:build, but no screenshot, recording, live Control UI output, or redacted runtime log showing the after-fix queued-approval modal behavior. (ef98bd1959a7)

Likely related people:

• BunsDev: Authored the native dialog-backed Control UI modal migration that introduced openclaw-modal-dialog and moved exec approval prompts onto it. (role: introduced modal behavior; confidence: high; commits: e5a5ea10722e; files: ui/src/ui/components/modal-dialog.ts, ui/src/ui/views/exec-approval.ts)
• jesse-merhi: Authored recent stale approval prompt and approval decision/controller work in the same Control UI approval queue path. (role: approval queue area contributor; confidence: high; commits: 5297eebe8837, 42f0822bfac9; files: ui/src/ui/controllers/exec-approval.ts, ui/src/ui/app.ts, ui/src/ui/views/exec-approval.ts)
• vincentkoc: Authored recent Control UI gateway startup/reconnect work near the hello path where this PR adds approval-list refresh. (role: recent Control UI reconnect contributor; confidence: medium; commits: f49f5973b0c1, c69a8d633d45, 8c8c8c8e32e2; files: ui/src/ui/app-gateway.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.