[macOS] Main window repeatedly ignores mouse and keyboard while native menu bar remains usable #52980

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

26.1007.21159 (build 20052), verified from the installed application's Info.plist. Bundle identifier: com.openai.codex. The About dialog was not used for this measurement.

What subscription do you have?

Not recorded in this diagnostic report.

What platform is your computer?

macOS 27.0.1 (26A434), Apple silicon / ARM64, 64 GiB system memory.

What issue are you seeing?

The Codex main window repeatedly stops accepting mouse and keyboard input while other applications remain usable. The native macOS menu bar still works. Normal quitting is possible; force quit was not required.

This has occurred at least twice, with the latest occurrence investigated on October 10, 2026, around 15:00–15:10 America/Chicago. Quitting and relaunching restored access temporarily, but the problem returned and is repeatedly interrupting work.

An earlier diagnostic exchange incorrectly characterized the menu bar as unresponsive. The user's explicit correction is authoritative: the menu bar remained usable.

What steps can reproduce the bug?

Observed sequence, not a deterministic minimal reproduction:

1. Use the Codex desktop app normally.
2. The main window begins ignoring mouse clicks and keyboard input.
3. Check other applications: their mouse and keyboard input still work.
4. Use the macOS menu bar: it remains usable, including the ability to quit normally.
5. Quit and relaunch Codex. Input returns temporarily, but the failure occurs again.

The exact triggering action and recurrence interval are unknown. Whether Computer Use was involved immediately before either occurrence is also unknown. No attachment, chat-reference, or specific project trigger has been established.

What is the expected behavior?

The main window should continue accepting input during normal operation. Recovery should not require repeated application restarts. If a particular task or UI surface is blocked, the rest of the window should remain usable.

Additional information

App remains alive during the input failure

Read-only tools and background communication continued during diagnosis. Three-second macOS sample captures were collected for the main application process and two renderer processes.

• The main application's main thread spent 262 of 265 sampled observations in its run-loop event wait, with occasional timer/source handling.
• The two sampled renderer main threads were predominantly in event waits (275/275 and 262/265 observations on those paths).
• These short samples do not identify the cause. They do not demonstrate a sustained main-thread busy loop and do not rule out input-routing or other UI-state failures. Symbols in the packaged Chromium/Electron framework are incomplete, so distant symbol names were not treated as precise source locations.

High-load confounder tested

Three codebase-memory-mcp helper processes were found using approximately one CPU core each and roughly 25 GiB combined resident memory. Only those three helpers were temporarily suspended. They subsequently showed 0% CPU, and the one-minute system load average fell from about 59 to 32. The user explicitly confirmed that input still did not work after that intervention. The high load is not established as the cause of the window-input failure.

Update offer discrepancy

The in-chat desktop update-check tool reported installed version 26.1007.21159 / build 20052 and an available version 26.1007.30912 / build 20156. However, the user reports that the application is not offering an upgrade, so they have not installed one. Please do not interpret this report as the user declining an actionable update. It is unknown whether the other build fixes this problem.

Possibly related reports

• [macOS] Mouse and keyboard input stops after adding images via paste or drag-and-drop; native menus still work #52242 describes loss of mouse and keyboard input with native menus still working, associated with image paste/drag operations.
• [Desktop/macOS] Renderer freezes after referencing large local Codex chats while backend tasks continue #34555 describes an unresponsive desktop window while backend work continues, associated with large chat references.

Those triggers have not been confirmed here, and a common root cause has not been established.

Only sanitized symptoms, aggregate process measurements, and application/OS versions are included. Private projects, prompts, account data, local usernames/paths, session identifiers, raw logs, and raw process samples are omitted. No in-app feedback ID has been generated for this report.