Codex Desktop thread switching is consistently slow on Windows

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

• #28735
• #28408

Powered by Codex Action

Codex Desktop has become significantly slower recently. Even simple questions or minor edits to a small file can take around five minutes, with long delays during both reasoning and tool execution. This issue occurs repeatedly on Windows and affects both new and existing threads, making routine tasks unnecessarily time-consuming.

Update after more isolation testing:

We did several additional Windows repro tests after restarting Codex and, separately, after a full laptop restart.

New observations:

• Cold-opening an existing thread after app/laptop restart is still slow, typically ~5-10s, and in one low-overhead capture felt closer to ~20s while testing.
• The same thread switches virtually instantly after it has been opened once in the current app session.
• A tiny thread with only a trivial prompt/reply still cold-opens slowly, then switches instantly once warm.
• A large thread can open instantly if it appears to already be warm/idle, so transcript size alone does not explain the behavior.
• Renaming a slow thread to a short title did not improve its first cold load.
• After that thread was opened once, switching back to it became virtually instant.

Process observations from low-overhead sampling during slow cold switches:

• Main Codex.exe consumed the most CPU and memory, peaking around ~1.2 GB working set.
• Renderer and GPU Codex.exe processes also showed significant CPU.
• codex.exe app-server showed some CPU, but less than the main app/renderer path in the cleanest capture.
• git.exe appeared as many tiny short-lived processes, but with negligible CPU.
• Windows Defender / MsMpEng.exe showed no measurable CPU movement during the captures.
• dwm.exe also showed no measurable CPU movement.

We also found one separate local contributor: an invalid/empty .git folder in one project root made switching worse. Removing it improved some timings, but did not fix the remaining cold-thread issue. The residual problem persists even when Git/Defender are quiet.

Current best hypothesis:

This looks less like Git, Defender, terminal shell choice, or transcript size, and more like a Codex Desktop cold thread hydration/resume/render path on Windows. Once a thread has been hydrated in the current app session, switching back to it is fast.

Possible useful repro refinement:

1. Fully quit Codex and end lingering Codex.exe/codex.exe processes.
2. Reopen Codex.
3. Open an existing thread that has not yet been opened in this app session.
4. Observe slow first load / possible “Not responding”.
5. Switch away and back to the same thread.
6. Observe near-instant warm switch.
7. Repeat with a tiny old thread to rule out transcript size.

Seeing the same issue on Windows 11 running WSL.

Feedback ID: no-active-thread-019ef5d4-c21c-7430-85bc-d61cfa924fbf

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

Additional update after more targeted capture:

We ran a 90-second process-tree watcher during a user-driven slow thread switch / return test on Windows.

Observed behavior:

• Windows showed “Not responding” at about ~7 seconds into the capture.
• In the first ~15 seconds, the main Codex.exe working set jumped from ~233 MB to ~1,058 MB.
• During that same first ~15s window:
• main Codex.exe: ~9.47 CPU-seconds
• renderer Codex.exe: ~5.92 CPU-seconds
• GPU process: ~2.81 CPU-seconds
• codex.exe app-server: ~1.19 CPU-seconds
• node_repl.exe: 0 CPU delta

Full 90-second capture summary:

• main Codex.exe: ~31.52 CPU-seconds
• renderer Codex.exe: ~27.53 CPU-seconds
• GPU process: ~17.94 CPU-seconds
• codex.exe app-server: ~4.94 CPU-seconds
• 8 node_repl.exe processes were present under codex.exe app-server; 7 were present from the start and 1 appeared partway through, but all showed 0 CPU delta.

Additional isolation since the last comment:

• Moving ~\.codex\.tmp\plugins outside the Codex tree did not improve switching. Codex recreated the plugin staging tree and latency remained/worsened, so this does not look like the primary cause.
• A switch-vs-idle capture showed the same log/state files changing in both cases, so logs_2.sqlite, state_5.sqlite-wal, models_cache.json, and .codex-global-state.json look more like background/tooling noise than the specific switch bottleneck.
• The strongest switch-specific signal remains main app / renderer / GPU CPU plus a large main-process memory jump during cold thread hydration.

Current read:
This still looks most consistent with a Codex Desktop cold thread hydration/resume/render path on Windows, where heavy app/renderer work blocks the UI long enough for Windows to mark the app “Not responding”. node_repl.exe helper fanout exists on this machine, but the latest capture did not show node_repl.exe CPU as the immediate freeze driver.

Other negative/isolating tests already run:

• Moving logs_2.sqlite, session files, generated images, plugin/runtime cache, and disposable app/web cache did not fix the issue.
• Moving the full Codex app profile did not fix it.
• Windows Efficiency Mode changes did not help.
• Temporary Defender exclusions did not help.
• Git probing was a real contributor earlier because of one invalid empty .git folder, but after removing that local issue, the remaining slow cold-switch behavior persisted with Git/Defender quiet.
• Tiny thread still cold-loads slowly, while warmed threads switch instantly, so transcript size/title length alone does not explain it.

Adding another Windows repro with lower-level file I/O evidence. This looks like the same user-visible issue as this thread, but the strongest signal in my capture is different from the earlier Git/app-server theories.

Environment:

• Codex Desktop package: OpenAI.Codex_26.623.8305.0_x64__2p2nqsd0c76g0
• PATH CLI: codex-cli 0.142.4
• OS: Windows 11 Pro 10.0.22631, x64
• Hardware: 20 logical processors, 31.7 GB RAM
• codex doctor --summary --ascii --no-color: 17 ok | 1 idle | 1 notes | 0 warn | 0 fail; state DB healthy; rollout files and state DB thread inventory agree; app-server was idle at doctor time.

Symptom:

• Normal Codex Desktop sidebar/thread switching causes multi-second whole-system input lag: mouse movement visibly drops to very low FPS while switching threads.
• The lag persisted after restarting/updating Codex, rotating the old large logs_2.sqlite, repairing stale workspace/thread cwd metadata, adding narrow Defender exclusions, using Chrome-only browser backend config, and resetting only the local Codex runtime cache under %LOCALAPPDATA%\OpenAI\Codex\bin and %LOCALAPPDATA%\OpenAI\Codex\runtimes.
• Deep-link navigation to a thread did not reproduce the same large read burst, so it appears specific to the normal UI/sidebar thread-switch path.

Perf-counter evidence from a manual sidebar/thread switch:

Trace: 20260629-163814-user-reported-thread-switch-read-burst-trace.csv

main Codex.exe read max:        1029.19 MB/s
second main Codex.exe burst:    1012.08 MB/s
main Codex.exe CPU max:         124%
main Codex.exe page faults/sec: 261,117
packaged app-server read max:   19.02 MB/s
npm app-server read max:        54.81 MB/s
Defender read max:              0 MB/s

Procmon evidence from an Administrator capture during manual thread switching:

Capture: 2026-06-29 16:48:29 local time
Parsed rows: 8,616,332
Successful Codex ReadFile rows: 11,491

Top Codex process by successful ReadFile bytes:
Codex.exe PID 36568: 6,192.81 MB across 659 events

App-server in same capture:
codex.exe PID 36072: 62.3 MB total requested reads

The key part: the main Desktop Codex.exe, not the app-server, repeatedly read full helper/runtime binaries from both the packaged app and the local runtime cache:

%ProgramFiles%\WindowsApps\OpenAI.Codex_26.623.8305.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
  323,007,280 bytes per read, 5 reads, 1540.22 MB requested total

%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe
  same size, 5 reads, 1540.22 MB requested total

...\app\resources\cua_node\bin\node.exe
  91,380,224 bytes per read, 15 reads, 1307.2 MB requested total

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node.exe
  same size, 15 reads, 1307.2 MB requested total

packaged + cached node_repl.exe
  13,963,776 bytes per read, 15 reads per location, 199.75 MB requested total per location

packaged + cached codex-windows-sandbox-setup.exe
  8,832,304 bytes per read, 5 reads per location, 42.12 MB requested total per location

This capture does not look like the old logs_2.sqlite reread issue:

app-server .codex\logs_2.sqlite-wal: 16.25 MB
app-server .codex\logs_2.sqlite:      4.09 MB

It also does not look like Defender doing the reads in this capture. Defender can spike CPU in some traces, but this Procmon run shows Codex itself issuing the repeated full-file reads.

Targeted cache reset did not help:

Reset scope:
- renamed only %LOCALAPPDATA%\OpenAI\Codex\bin
- renamed only %LOCALAPPDATA%\OpenAI\Codex\runtimes
- did not touch %USERPROFILE%\.codex, sessions, auth, config, or AppX install

After reset:
- Codex regenerated bin/runtimes
- manual sidebar/thread switch still reproduced the read storm

Post-reset warm trace:
main Codex.exe read max:        1256.55 MB/s
main Codex.exe CPU max:         136%
main Codex.exe page faults/sec: 276,509

Current hypothesis:

Normal Desktop UI/sidebar thread switching is triggering repeated helper/runtime validation, hashing, copy/reconciliation, or startup checks in the main Electron Codex.exe process. That work seems to reread large packaged and cached helper binaries multiple times and is happening on, or too close to, a UI-sensitive path. It probably needs to be cached/debounced, moved off the thread-switch path, or run only when the package/runtime version changes.

Related issues that look adjacent but not identical: #30428 has WPR evidence around UI stutter and app-server/Git churn; #28855 tracks broader Windows Desktop whole-system input lag. This comment adds Procmon path-level evidence that the remaining thread-switch hitch can be dominated by main-process full-file reads of runtime/helper binaries.

I am not attaching the raw Procmon .pml/CSV publicly because the raw capture is several GB and may include sensitive local activity. I have a small parsed summary and can provide a redacted bundle through an appropriate private channel if useful.