Codex Desktop frequently freezes during file-edit tool calls, making core editing unreliable

[thughy]

What version of the Codex App are you using?

Current running Codex Desktop bundle inspected locally:

• Codex Desktop: 26.519.41501 (bundle build 3044)
• Packaged Codex CLI inside the running desktop app: codex-cli 0.133.0-alpha.1
• Global CLI also installed on this machine: codex-cli 0.125.0

This is not limited to this exact build. The same class of freeze has been observed repeatedly across multiple Codex Desktop versions.

What subscription do you have?

The user has access to GPT-5.5 modes. I am not including the exact subscription tier because I cannot safely infer it from the local environment.

What platform is your computer?

• macOS 15.6.1 (24G90)
• Darwin 24.6.0
• arm64
• MacBook Pro Mac16,1, Apple M4, 16 GB RAM

Which model / mode were you using?

Observed repeatedly in both:

• GPT-5.5 high-speed mode
• GPT-5.5 normal-speed mode

So this does not look like a single model-speed-mode issue.

What issue are you seeing?

Codex Desktop frequently gets stuck or becomes effectively frozen exactly when the agent is about to output or execute a file-edit command, usually the file-edit / apply_patch path. The workflow blocks waiting for the edit command instead of returning prompt success or a clear failure.

This is a severe product reliability problem. File editing is the core job of Codex. A coding agent that repeatedly freezes while editing files is not just showing a rough edge; it is failing at the central user workflow. This needs immediate prioritization by the OpenAI team, not eventual polish.

Observed behavior:

• Codex reaches the file-edit step during an otherwise normal desktop session.
• The edit command stalls or appears to hang instead of applying the change or failing with a useful diagnostic.
• The user is left with a blocked workflow and no clear recovery path.
• In practice the workaround is to wait too long, abandon the turn, restart, or try to force the agent into some other editing method.
• The problem recurs often enough to seriously damage trust in Codex Desktop.
• The problem appears across both GPT-5.5 high-speed and normal-speed modes.
• The user reports seeing this class of issue in almost every recent Codex Desktop version.

Expected behavior:

• File-edit tool calls must return deterministically.
• If the edit applies, Codex should report success promptly.
• If the edit cannot be applied, Codex should fail promptly with a specific, actionable error.
• The Desktop UI must remain responsive while a tool call is running.
• The user should have an obvious cancel / retry path if an edit command exceeds a short timeout.

What steps can reproduce the bug?

The issue is intermittent, but the pattern is consistent:

1. Open Codex Desktop on macOS.
2. Start or continue a normal local coding session.
3. Ask Codex to make a small edit to an existing source file.
4. Let Codex proceed until it starts emitting or executing the file-edit command.
5. Intermittently, Codex stalls at this exact edit-command stage instead of applying the patch or returning a useful failure.

This has happened frequently during normal usage rather than only under a contrived stress test.

Related issues

This appears related to existing tool-call / patch hangs, but the user-visible failure here is specifically in Codex Desktop and severe enough to deserve desktop-app triage:

• apply_patch intermittently hangs/stalls without returning success or error #24155
• macOS: internal apply_patch intermittently times out on simple edits #17834

Please treat this as a high-priority reliability bug. If the root cause cannot be fixed immediately, Codex Desktop at minimum needs a bounded timeout, a visible error, and a reliable retry/cancel mechanism so the entire editing workflow does not silently freeze.

[github-actions]

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

• apply_patch intermittently hangs/stalls without returning success or error #24155

Powered by Codex Action

[jshaofa-ui]

Proposed Solution: File-Edit Freeze - Async I/O with Worker Thread

Root Cause

File-edit tool calls execute synchronous file I/O on the main Electron renderer thread. For files >100KB or on slow storage, this blocks the UI completely with no progress indication or timeout.

Fix

Offload file-edit I/O to a worker thread with timeout:

const worker = new Worker('./file-edit-worker.js', { workerData: params });
const timeout = setTimeout(() => { worker.terminate(); reject(new Error('Timeout 30s')); }, 30000);
worker.on('message', (result) => { clearTimeout(timeout); resolve(result); });

Impact

• Severity: High - core editing functionality unreliable
• Scope: All Codex Desktop users

Testing

1. File-edit on 10MB file - verify no UI freeze
2. Simulate slow I/O - verify timeout triggers correctly

Full solution: solutions/codex-24206-file-edit-freeze-fix.md

[Yan-c-c]

Me Too