Severe multi-minute tool latency and inconsistent writable-root permissions in Codex Desktop on Windows

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

26.715.61943

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Title: Severe multi-minute tool latency and inconsistent writable-root permissions in Codex Desktop on Windows

Severity: High — routine one-line edits take 1–4 minutes and trivial read-only tool calls take 20–50 seconds.

Environment

Product: Codex Desktop on Windows

Codex Desktop version observed: 26.715.8383.0

Command runner version observed: 0.145.0-alpha.27

Time zone: Australia/Sydney

Antivirus registered: Norton 360 and Microsoft Defender

Tests performed both inside a repository and in C:\tmp outside every Git repository

Summary

Codex tool execution is experiencing extreme latency. The most obvious symptom is apply_patch taking between 81 and 258 seconds to create a one-line file.

The issue persists after:

Closing unnecessary Claude processes

Restarting Codex

Starting a completely separate Codex task

Performing a full Windows reboot

Testing outside any Git repository

Using a one-line patch with no meaningful parsing or filesystem workload

Read-only shell calls are also sometimes delayed by 20–50 seconds. This suggests that apply_patch is the most visible symptom of a broader Codex tool-broker, worker-scheduling, IPC, or Windows sandbox problem.

Reproduction

Start a new Codex task on Windows.

Do not open or inspect a Git repository.

Work only in C:\tmp.

Confirm C:\tmp\codex-fresh-session-patch-probe.txt does not exist.

Use apply_patch to create it with exactly one line:Fresh-session patch probe.

Measure elapsed wall time.

Delete only the probe file.

Measured results

Existing long-running task, after restarting Codex:

One-line apply_patch in C:\tmp: 258.298 seconds

Brand-new task after a full Windows reboot:

First run: 151.860 seconds

Second run: 81.068 seconds

All runs classify as over 10 seconds; expected performance is under 2 seconds.

Additional tool latency observed

Simple Test-Path calls: approximately 25–51 seconds in the fresh task

Reading one local instruction file: approximately 24 seconds

A read-only text search: approximately 27 seconds

Codex manual helper invocation: approximately 25 seconds

Permission inconsistency

C:\tmp was declared as a writable root.

Despite this:

Normal Remove-Item calls in the fresh task failed after 25–49 seconds with “Access denied.”

The exact targeted deletion succeeded when elevated.

In another task, deletion from C:\tmp succeeded normally in approximately 2.2 seconds.

Creating C:\tmp\openai-docs-cache failed with EPERM despite C:\tmp being declared writable.

Creating the same cache under the Windows-designated %TEMP% directory succeeded.

This suggests inconsistent sandbox permission evaluation or retry behaviour rather than a stable filesystem ACL problem.

Control measurements

The underlying machine and repository operations are fast:

Direct temporary-file writes: approximately 2.3–2.4 ms per write

500 local file opens: approximately 171 ms total

100 full file reads: approximately 215 ms total

Git status: approximately 229 ms

Node startup: approximately 311 ms

Full project documentation validation: approximately 4 seconds

Disk latency: approximately 2–3 ms with no meaningful queue

One underlying test completed in 1.21 seconds while the surrounding Codex tool operation took approximately 30.5 seconds

Process investigation

Multiple idle MCP helper processes were found.

No orphaned helpers were found; each had a live parent.

Closing Claude reduced MCP helpers from 18 to 5.

This reclaimed memory but did not improve apply_patch latency.

The remaining helpers belonged to Codex and showed no meaningful CPU usage.

Likely affected layer

The evidence points away from Git, repository size, patch complexity, disk performance, Node, tests, and ordinary filesystem performance.

Most likely causes, in order:

Codex tool-broker or worker scheduling delay

Windows sandbox initialization, permission evaluation, or retry timeout

IPC or post-tool-call synchronization delay

apply_patch-specific overhead layered on broader tool-execution latency

Antivirus/file-filter interaction, although this is less likely because read-only commands and tool completion reporting are also delayed

Expected behaviour

A one-line local patch should complete in under two seconds.

A configured writable root should permit creation and targeted deletion without elevation.

Trivial read-only commands should complete close to their underlying process runtime.

Observed behaviour

One-line patches require 81–258 seconds.

Trivial reads sometimes require 20–50 seconds.

Writable-root permissions are inconsistent.

Restarting Codex, starting a fresh task, and rebooting Windows do not resolve the problem.

Impact

Routine coding operations become impractical.

Tool polling and repeated status turns consume unnecessary model context/tokens.

Tasks remain blocked for minutes even when the underlying command completes in milliseconds or seconds.

Permission inconsistencies cause avoidable elevation requests.

Requested investigation

Please investigate the server/client tool-execution traces around these timestamps:

21 July 2026, approximately 10:39 PM Australia/Sydney: 151.860-second patch

22 July 2026, approximately 7:57 AM Australia/Sydney: 81.068-second patch

Earlier on 21 July 2026: 258.298-second patch after restarting Codex

Please confirm:

Whether this matches a known Codex Desktop or Windows sandbox issue

Whether tool requests are waiting in a broker queue or retry timeout

Why C:\tmp is sometimes denied despite being declared writable

Where users can obtain stable request IDs or diagnostic logs

Whether there is a temporary workaround or updated client/runner available

No permanent cell IDs or internal trace IDs were exposed in the UI. The displayed cell numbers were reused between turns.

What steps can reproduce the bug?

as above

What is the expected behavior?

Useable speed - currently unworkable

Additional information

_No response_