›_ Codex Issues
Codex Issues / #33719

apply_patch stalls for several minutes after patch generation while token usage continues, and the file is not modified

Open 💬 3 comments Opened Jul 17, 2026 by bait0ngxaxa
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.144.4

What subscription do you have?

plus

Which model were you using?

gpt-5.6

What platform is your computer?

Windows 11

What terminal emulator and version are you using (if applicable)?

Powershell

Codex doctor report

What issue are you seeing?

After upgrading to GPT-5.6, I frequently experience a severe delay when Codex applies file changes.

The agent completes its reasoning and displays the generated patch or the code it intends to write. However, the actual file in the workspace is not modified immediately.

I consistently have to wait around 2–3 minutes before the file is updated. In some cases, the operation stalls for more than 5 minutes and eventually fails without modifying the file at all.

During the entire waiting period, token usage continues to increase even though:

The reasoning appears to have already completed.
The generated patch is already visible in the UI.
No actual changes have been written to the file.
The task may eventually fail without producing any usable result.

This causes a significant amount of token usage to be consumed while no work is completed.

What steps can reproduce the bug?

  • Open a project in Codex.
  • Use a GPT-5.6 model.
  • Ask the agent to modify an existing file.
  • Wait for the agent to finish reasoning and generate the patch.
  • Observe that the patch or intended code is displayed in the UI.
  • Check the actual file on disk.
  • The file remains unchanged for approximately 2–3 minutes, and sometimes for more than 5 minutes.
  • Observe the token usage during this period.
  • Token usage continues to increase while waiting for the patch operation to complete.
  • In some cases, the patch eventually fails and the file is never modified.

What is the expected behavior?

Once the agent has completed reasoning and generated the patch:

The patch should be applied to the file within a reasonable amount of time.
Token usage should not continue increasing while the local patch or filesystem operation is stalled.
If the patch cannot be applied, the operation should fail quickly with a clear error.
Codex should not continue consuming tokens while waiting on a blocked or failed file-write operation.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32819
  • #32790
  • #33671

Powered by Codex Action

yyc20057710-boop · 1 month ago

CLI tool calls stall for minutes on Windows, while Desktop appears unaffected

What version of Codex CLI is running?

codex-cli 0.144.5

What platform are you using?

Windows 11

What terminal are you using?

PowerShell

What model were you using?

gpt-5.6-luna

Issue description

Codex CLI frequently stalls while executing tools, especially apply_patch.

The model finishes reasoning and generates the patch, but the tool call remains stuck in a running state for several minutes. During this time, the file is not modified and token usage continues to increase.

In one recent session:

  • apply_patch started at approximately 2026-07-17 10:00:03 China Standard Time.
  • It returned no output after 10 seconds.
  • It remained running through two additional 60-second waits.
  • It finally returned {} after approximately 149 seconds.
  • The patch was eventually applied, but the delay was around 2 minutes and 29 seconds.

Other local tools such as Get-Content and git diff also occasionally take 50–80 seconds to return.

Desktop vs CLI behavior

The same machine appears to have different behavior between Codex Desktop and Codex CLI:

  • The issue is reproducible in CLI sessions (originator: codex-tui, source: cli).
  • Recent Desktop sessions have not shown the same multi-minute apply_patch stall.
  • Both appear to use the Windows sandbox and codex-command-runner-0.144.5.

This suggests the issue may be specific to the CLI tool execution or terminal integration path rather than the model response itself.

Relevant logs

The affected session log records repeated states similar to:

apply_patch started
Script running with cell ID ...
Wall time 10.0 seconds
Script running with cell ID ...
Wall time 60.0 seconds
Script running with cell ID ...
Wall time 60.0 seconds
Script completed
Wall time 17.0 seconds
Output: {}
ygireesh · 1 month ago

I am seeing essentially the same issue in Codex Desktop on Windows 11, not only in the CLI.

Environment

  • Codex Desktop / ChatGPT Windows app
  • Windows 11
  • Model: GPT-5.6 Sol Medium
  • Local repository on the C: drive
  • PowerShell
  • Normal single-repository workspace, not a multi-repo umbrella workspace

Behaviour

Small edits repeatedly stall during the patch-application stage.

Examples:

  • A one-line, single-file edit caused the patch service to stall twice.
  • Both attempts were eventually stopped without any partial write.
  • Subsequent small edits repeatedly displayed messages such as:
  • “The initial patch is applying more slowly than usual”
  • “The patch service is again taking an unusually long time to apply a small edit”
  • Sometimes Codex waits for several minutes before the file is modified.
  • Sometimes the patch fails and no file is modified.

The slowdown also affects basic agent tool calls:

  • I asked Codex to run only git status --short and read the first 10 lines of firestore.rules.
  • That took approximately 33 seconds.
  • Running Get-Content .\firestore.rules -TotalCount 10 directly in normal PowerShell completed immediately.

Troubleshooting already performed

  • Started fresh Codex tasks
  • Fully restarted the application
  • Reinstalled the Windows application
  • Confirmed the Git working tree was clean
  • Confirmed that the repository and files respond immediately in external PowerShell

The issue remained after the clean reinstall.

This suggests that Desktop is also affected, contrary to the current comment stating that recent Desktop sessions appear unaffected.

This may share a root cause with:

  • #32819
  • #32136

Please let me know which logs or session diagnostics would be useful. I also have screenshots showing the repeated patch-service delay messages.