Codex desktop input freeze

Open 💬 2 comments Opened Jun 7, 2026 by treyo1-ui

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Desktop

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Title: Codex desktop input composer freezes / stops accepting input

Product: Codex desktop app
OS: macOS
Issue:
The prompt/input box intermittently freezes and stops accepting input. This occurs in a bounded thread, not unusually long compared with other working threads. It blocks human-in-the-loop review and approval-token entry.

Context:

Repo-native Codex workflow
Tool calls active in prior turns
In-app browser may be open to a local file:// artifact
Restart/reload may temporarily help

Expected:
The input composer remains responsive regardless of thread/tool/browser state.

Actual:
The composer becomes unresponsive and prevents further typing.

Impact:
Major blocker for iterative Codex workflows and approval-gated review.

Please advise whether logs, thread/session ID, or app diagnostics would help.

What steps can reproduce the bug?

Simply working. Even on short threads

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#26368
#25481

Powered by Codex Action

nate2022-ai · 2 months ago

I am seeing a repeated macOS Codex Desktop input freeze that appears to be the same class of issue, but this occurrence has a few additional diagnostics.

Environment:

Codex Desktop app: 26.623.42026
Bundled Chromium / Electron framework: 149.0.7827.197
Bundled Codex CLI: codex-cli 0.142.3
macOS: 26.5.1 (25F80)
Platform: Apple Silicon / arm64

Observed behavior:

The Codex Desktop composer repeatedly stops accepting input.
Earlier occurrences showed no caret / no text cursor, while the rest of the window remained clickable.
In the latest occurrence, after renderer recovery, the caret became visible again, but neither physical keyboard input nor switching input methods produced any text.
Other apps could still receive keyboard input normally, so this does not look like a global macOS keyboard or IME failure.
Cmd+R did not restore the composer in this occurrence.
Fully quitting and reopening Codex is the only reliable recovery so far.

What I tried during the stuck state:

Cleared accumulated helper processes under the Codex backend process:
node_repl
SkyComputerUseClient
Sent Cmd+R to the Codex window.
Killed old Codex (Renderer) processes and let Codex recreate renderer processes.
Stopped codex_chronicle, SkyComputerUseService, bare-modifier-monitor, and accumulated helper processes, then refreshed again.
Sent a synthetic text event via macOS System Events (codex_input_test) without confirming that text entered the composer.
Queried the current focused UI element through macOS accessibility; it returned no readable AXFocusedUIElement, even though the composer visually showed a caret.

Process / state observations:

There were no new Codex crash reports in ~/Library/Logs/DiagnosticReports.
Before cleanup, the Codex backend process had multiple long-lived helper pairs:
node_repl
SkyComputerUseClient
Some had been alive for 50+ minutes.
codex_chronicle, ScreenCaptureKit, replayd, and TCC permission checks were very active in the same time window.
After helper cleanup and renderer recreation, Codex automatically spawned new SkyComputerUseClient / node_repl helpers.
During the stuck state, Codex main / renderer processes still showed elevated CPU, but the app was not fully crashed.

Sample files generated locally during the stuck state:

/tmp/Codex_2026-06-28_205533_SUnS.sample.txt
/tmp/Codex_(Renderer)_2026-06-28_205531_XC2m.sample.txt
/tmp/codex_2026-06-28_205535_Vsi3.sample.txt

Hypothesis:

This looks like a Codex Desktop renderer / web composer input-event state bug rather than a normal focus-only issue. The latest recurrence reached a state where the caret was visually present, but text input events were not delivered to the composer. codex_chronicle, ScreenCaptureKit, Computer Use helpers, and renderer state recreation may be involved or may amplify the issue, but local helper cleanup did not fix it.

Impact:

This blocks interactive approval/review workflows because the app can remain clickable while the composer cannot accept user input. Reload/restart is disruptive and loses the current live working state.