[macOS] In-app browser WebAuthn/passkey dialog leaks into other threads and cannot be dismissed (Close/Cancel/Esc ignored) — only app restart clears it

Summary

A WebAuthn (passkey / security key) prompt raised by the in-app browser in one thread stays on screen after switching to another thread. It renders on top of the other thread's view, and none of its buttons work: Close, Cancel, Try again, Esc and Return do nothing. After the WebAuthn request times out the sheet turns into "Something went wrong — The request timed out" with a Close button that is equally dead. The only way to get rid of it is to quit the whole Codex Desktop app, which interrupts every running thread.

Environment

• Codex Desktop (macOS) 26.903.71938 (build 8576), bundled codex-cli 0.153.4
• Codex Framework (Chromium) 152.0.7977.83
• macOS 27.0 (26A428), Apple Silicon (arm64)
• Sign-in: ChatGPT Pro account; model_provider is a custom provider (CLIProxyAPI), which should not matter for the browser UI

Steps to reproduce

1. In thread A (sidebar name "Updates"), use the in-app browser (agent-driven, browser plugin) to open https://dash.cloudflare.com and start signing in. Cloudflare asks for a passkey / security key, so the browser shows the Chromium WebAuthn sheet ("Use a saved passkey for dash.cloudflare.com" with "Use a phone or tablet" / "USB security key" / "Cancel").
2. While the sheet is up, switch to a different thread B in the sidebar (thread B shows a Jira page in its own in-app browser tab).
3. Observe: the WebAuthn sheet from thread A is still displayed, centered over thread B's browser pane.
4. Click Cancel. Press Esc. Nothing happens.
5. Try a hardware key that is not registered: the sheet becomes "Try a different security key — You're using a security key that's not registered with this website" with Close / Try again. Both buttons are dead.
6. Wait for the WebAuthn timeout: the sheet becomes "Something went wrong — The request timed out" with Close. Still dead.

Expected

• The WebAuthn sheet is tab-modal for the tab that requested it: when the user switches to another thread it should be hidden (or at least stay attached to thread A), not cover thread B.
• Cancel / Close / Esc should dismiss it from any thread, and once the request has timed out the dialog must be closable.

Actual

The dialog is a separate NSWindow of the app (is_main: false, 448×300 / 448×387 px, titled "Try a different security key" → untitled passkey sheet → "Something went wrong") that stays over whichever thread is active. Accessibility inspection of that window:

• AXSubrole = AXUnknown, the only action is AXRaise
• AXCloseButton, AXCancelButton, AXDefaultButton all resolve to missing value
• The AXButton "Close" / "Cancel" children accept AXPress (the action is reported as performed) but the window does not react
• Real mouse clicks on the buttons (CGEvent) and Esc / Return key presses are ignored as well

So the sheet is attached to a WebContents that is no longer the visible one, and the constrained-window input routing is broken once the owning thread is not in front.

Impact

The user cannot work in any thread while this window is present (it covers the browser pane and steals the visual focus). The only workaround, quitting Codex Desktop, kills all in-flight turns. Killing the owning tab is not possible from the UI either: the agent's in-app browser tab is not listed in the tab strip.

Logs / evidence

• Thread that raised the prompt: 01a090b0-a6cf-76f0-aca4-b3cb41d0e2a3 (sub-agent threads 01a09268-…, 01a09276-…), rollouts contain the dash.cloudflare.com navigation at 2026-09-11T21:50:27Z and 21:54:12Z.
• Screenshot of the final state (dialog over an unrelated Jira page in thread "WeeklyReport") is attached as a comment below.
• Happy to provide ~/.codex/logs_2.sqlite excerpts or a screen recording on request.

Related

#31204 and #29346 are about the in-app browser not invoking WebAuthn at all; this report is the opposite case: the prompt is shown, but it is bound to the wrong surface and cannot be dismissed.

Reproduce the listed thread-switching flow in the in-app browser, then trace how the WebContents WebAuthn prompt is attached to the macOS NSWindow and how input is routed after switching threads or timing out. Done means the prompt stays with its owning thread or is hidden on switch, and Close, Cancel, Esc, and timeout-state dismissal work without restarting the app.