Codex Desktop on macOS becomes completely unable to accept input (total lock-out); only Force Quit restores it

What version of the Codex App are using (From About Codex dialog)?

Codex Desktop 26.623.61825 (CFBundleVersion 4548, bundle id com.openai.codex)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.5.1 (build 25F80), Darwin 25.5.0, arm64

What issue are you seeing?

Codex Desktop on macOS frequently becomes completely unable to accept any keyboard input — not just the composer. The lock-out is total:

• Clicking inside the composer: no caret appears
• Typing into any focused Codex field: nothing arrives
• Switching to another macOS app and back with Cmd+Tab does not recover focus
• Closing/reopening the Codex window does not recover focus
• Closing and reopening the conversation/thread does not recover focus
• The only reliable recovery is fully quitting Codex Desktop (Cmd+Q or Force Quit) and relaunching

This is more severe than the focus-loss already tracked in #30346: there, "switch focus away and back" was enough to restore the caret. Here the input pipeline appears fully wedged and focus-nudge workarounds have no effect.

For someone in the middle of a long-running Codex task (e.g. an agent that is driving a real project), force-quitting Codex kills the in-flight session and is extremely disruptive — the work and chat history have to be recovered from the cloud on next launch, and any state tied to the running UI is lost.

Environment / context:

• Product: Codex Desktop (Electron build), not CLI
• Date observed: 2026-06-30
• Observed both while Codex was actively generating a response and while it was idle
• Trigger is not clearly tied to switching apps, opening settings, or to a specific thread — feels intermittent and fairly frequent
• macOS input sources: default English (US); no IME switching happening at failure time

What steps can reproduce the bug?

Cannot pin down a deterministic trigger yet. Most consistent pattern observed:

1. Have Codex Desktop open with an active conversation (typically a long-running thread driving a coding project)
2. Use Codex for a while — typing, sending, getting responses
3. At some point, return to the composer and notice no text is being captured — the input box appears focused (or no field is focused) but keystrokes do not produce characters and clicks do not place a caret
4. Trying Cmd+Tab to another app and back, clicking around, or closing/reopening the conversation does not fix it
5. The first Cmd+Q + relaunch always restores normal input

What is the expected behavior?

• Composer remains focusable and accepts keyboard input even after long sessions, app/space switching, and idle periods
• If a focus-recovery issue is unavoidable, it should be recoverable in-app (e.g. by switching conversations or by clicking an empty region) — not require a full Codex quit that drops in-flight agent sessions

What do you see instead?

Total input lock-out. No text entry is accepted anywhere inside Codex Desktop. Force quit + relaunch is the only reliable fix, and this happens often enough to seriously disrupt normal usage while a project is in progress.