Codex Desktop thread switching is consistently slow on Windows

[HouseOfCog]

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

Version 26.616.32156 • Released 19 June 2026

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop thread switching is consistently slow on Windows.

Environment:

• Codex Desktop version: 26.611.61753
• OS: Windows
• Shell originally: PowerShell 5.1
• Integrated terminal shell changed to Command Prompt, persisted in config.toml as integratedTerminalShell = "commandPrompt"

Symptom:

• Cold-opening/switching to any thread takes roughly 6 seconds.
• This happens even after fully quitting Codex / ending the Codex task and reopening.
• It also happens for a brand-new tiny thread with a trivial request, so thread transcript size does not appear to be the cause.
• Warm switching is much faster once the thread has already been opened.

Relevant log evidence:

• During thread/start and thread/resume, logs repeatedly show:
  Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell
• This still appears after changing Integrated terminal shell to Command Prompt.

Question:
Is Codex session initialization still using PowerShell internally despite the integrated terminal setting, and could that be causing the fixed ~6s cold thread activation delay?

What steps can reproduce the bug?

Switch to a thread that hasn't been opened yet in the current session.

What is the expected behavior?

Switching threads happens within 1 second.

Additional information

No response

[github-actions]

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

• Codex Desktop Windows 26.611.61753: chat switching and composer typing feel laggy #28735
• {"timestamp":"2026-06-15T23:33:04.169971Z","level":"WARN","fields":{"message":"Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell"},"target":"codex_core::shell_snapshot"} #28408

Powered by Codex Action

[AnnidLin]

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.

[HouseOfCog]

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.

[moinmir-pci]

Seeing the same issue on Windows 11 running WSL.

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

[Yassycodes]

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: #29949 (comment)

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.

[HouseOfCog]

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.