[macOS] Mouse and keyboard input stops after adding images via paste or drag-and-drop; native menus still work #52242

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

26.1002.52244 (build 13536).

Read from the installed application's Info.plist and bundled package metadata; the About dialog was not inspected. Bundle identifier: com.openai.codex.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Darwin 27.0.0 arm64 arm

Output of uname -mprs. macOS 27.0.1 (26A434), MacBook Pro with Apple M4 Max and 48 GiB RAM.

What issue are you seeing?

The Codex window stops accepting mouse clicks, typing, and keyboard shortcuts while preparing a task with screenshot attachments. This happened three times on this Mac on October 8, 2026:

• First two occurrences: preparing a new task in an existing project, with a prompt and ten screenshots pasted individually using ⌘V.
• Third occurrence: the same input-blocking symptom while dragging images into the interface. The number of images and exact drag source were not recorded for this occurrence.

During the earlier occurrences, native macOS menu-bar and Dock context-menu commands still worked. For example, choosing a command to create a project through the native menu changed the visible interface, even though clicking inside the window and typing did nothing.

Restarting the application restored input after each occurrence. No visible error message was preserved. The original prompt and screenshots are private and are omitted.

What steps can reproduce the bug?

Observed sequence, rather than a deterministic minimal reproduction:

1. Open Codex on the environment above and prepare a new task in an existing project.
2. Add screenshot attachments. In the first two occurrences, paste ten screenshots one at a time using ⌘V. Dragging images into the interface also triggered a third occurrence.
3. Try to type in the composer, click controls inside the window, or use keyboard shortcuts.
4. Observe that input inside the window is ignored. During the earlier occurrences, native menu commands still remained usable.
5. Quit and relaunch the application; normal input returns.

The exact triggering image, count threshold, and success rate are unknown. This has not been tested with a clean profile or a controlled image set. The first two failures occurred while preparing the task; a completed prompt submission was not confirmed, so token/context usage is unavailable.

What is the expected behavior?

Adding images should leave the composer and the rest of the window interactive. If an attachment cannot be processed, show a recoverable error and allow the user to continue without restarting.

Additional information

Local diagnostics collected after the occurrences (times below are Moscow, UTC+03:00, on October 8, 2026):

• Crashpad sidecar metadata for both browser and renderer records capture_kind=dump_without_crashing around 19:09:33, 19:21:32, and 22:10:19. These are diagnostic captures; the metadata alone does not prove a crash, hang mechanism, or root cause. No retained stack dump was available.
• For the first two occurrences, macOS WindowServer logs show keyboard events routed to the application's main process. This does not prove that the renderer received or handled them.
• During the second occurrence, AppKit logs record requests for public.png from the clipboard, including one at 19:21:32.327. Eleven requests were recorded between 19:13:20 and 19:21:32; these cannot be equated with eleven distinct or successfully attached images.
• Before the latest restart, the desktop log contains ResizeObserver loop completed with undelivered notifications. three times at 22:08:05. Its relationship to the input failure is unknown.
• The latest desktop log ends at 22:10:54, and the next launch starts at 22:10:58, consistent with the reported restart.
• No Codex OOM or GPU-reset evidence was found in the retained logs examined for the first two occurrences. Renderer memory during the failures was not measured. Fresh macOS unified-log queries for the third occurrence were blocked by the agent sandbox, so input routing for that occurrence was not independently checked.

Related reports checked before filing: #34555 describes a similar loss of window input with a different trigger; #51944 describes a drag-pasteboard hang on macOS 27 where copy-paste works and the whole app blocks. This case also occurred with ⌘V, and native commands remained usable in the earlier occurrences. A shared cause has not been established.

Only redacted diagnostic facts are included here; raw logs, screenshots, private prompts, and account/session data are not attached.