[Windows 11] apply_patch stalls for 40–60 seconds before one-line file mutation in Codex CLI 0.144.1 #32477

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.6-sol, reasoning high The same severe apply_patch slowdown also reproduced with multiple other GPT-5.6 Codex models, so it does not appear to be specific to gpt-5.6-sol.

What platform is your computer?

Windows 11 x64, native Windows environment, not WSL

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

Native PowerShell session on Windows 11

Codex doctor report

Not collected. Codex CLI /status output is included in Additional information.

What issue are you seeing?

apply_patch consistently takes approximately 40–60 seconds to perform a trivial one-line file edit on native Windows 11.

Direct filesystem writes through Node.js, Bun, and PowerShell complete in under approximately one second of total tool-call wall time, while the actual filesystem mutation itself takes milliseconds or less.

An independent Bun watcher polling the target file every millisecond showed that virtually the entire apply_patch delay occurs before the target file is mutated. Once the mutation becomes visible, the tool call completes within 1–17 ms.

There is no visible approval prompt during the delay. Codex stalls silently, the file eventually changes, and the tool call then returns almost immediately.

Full wall-clock benchmark

All measurements cover the complete Codex tool call, from immediately before dispatch until the result returned.

Additional apply_patch calls made while preparing the benchmark took:

• 38.933 seconds
• 46.482 seconds
• 60.449 seconds

Actual filesystem write durations

Patch phase timing

An independent Bun process polled the target file every millisecond.

The benchmark cannot distinguish whether the delay happens before the patch helper process starts or during pre-write validation inside the helper. It does definitively localize the delay to the combined pre-write phase.

Troubleshooting already performed

The behavior did not materially improve after:

• closing Android Studio and the Android emulator,
• temporarily disabling Windows real-time antivirus protection,
• testing outside the repository under C:\tmp,
• temporarily excluding Git metadata as the cause,
• testing multiple GPT-5.6 Codex models,
• restarting and using fresh Codex sessions.

The repository contains approximately 85,000 filesystem entries, including approximately 80,000 under node_modules, but direct enumeration completed in approximately 0.5 seconds.

The delay is therefore unlikely to be caused by disk performance, normal filesystem writes, Git, node_modules, repository size, Android Studio, the Android emulator, or Windows real-time antivirus scanning.

The current workaround is to avoid apply_patch and use targeted Node.js node:fs edits instead.

What steps can reproduce the bug?

1. Start Codex CLI 0.144.1 on native Windows 11.

2. Use a normal workspace session with permissions set to Workspace (Ask for approval).

3. Create a disposable text file containing a single line: a.

4. Ask Codex to use apply_patch to change that line from a to b.

5. Measure the full tool-call wall time, from dispatch until the tool returns.

6. Observe that no approval prompt appears. The apply_patch call stalls silently for approximately 40–60 seconds.

7. Monitor the target file from a separate process. The file remains unchanged during virtually the entire delay.

8. Once the mutation becomes visible, the tool call completes within several milliseconds.

9. Repeat the test in both:

   • the active repository;
   • a disposable directory under C:\tmp.

10. Compare the result with an equivalent targeted edit using Node.js node:fs, Bun, or PowerShell. These methods complete in under approximately one second of total tool-call wall time.

The behavior reproduces consistently across repeated runs.

What is the expected behavior?

A trivial one-line apply_patch operation should start promptly and complete within a few seconds.

Its latency should be reasonably comparable to other local file-editing methods and should not introduce a consistent 40–60 second pre-write delay before every file mutation.

Additional information

Sanitized /status

OpenAI Codex v0.144.1

Model:              gpt-5.6-sol
Reasoning:          high
Directory:          Windows workspace
Permissions:        Workspace (Ask for approval)
Collaboration mode: Default
Subscription:       ChatGPT Plus

No permission or approval dialog appears during the delay.

The issue also reproduced with multiple other GPT-5.6 Codex models, so it does not appear to be specific to gpt-5.6-sol.

A private OpenAI Support ticket containing the complete benchmark and session identifier has already been escalated to a support specialist. I am not including the account email address or full private session identifier in this public issue.

Potentially related issue: #32314.

The behavior described here is narrower and specifically isolates approximately 50 seconds of latency in the pre-write path of apply_patch.