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.

This remains reproducible on the current Windows build:

• Codex/ChatGPT Desktop package: OpenAI.Codex 26.721.4979.0
• OS: Windows 11 Enterprise, 10.0.26200 x64
• Connection: approximately 1 Gbps downstream, 100 Mbps upstream, approximately 6 ms ping
• VPN: split tunnel; only work network destinations use the VPN, while OpenAI traffic uses the normal internet connection

Switching between existing local Codex chats in a project now takes about 10 seconds before the history is usable. It was previously close to instantaneous. This has been happening for at least several days and materially affects my work because I switch chats frequently.

The problem persists after:

• fully quitting and reopening the application many times
• installing multiple application updates
• restarting Windows many times

These are local Codex chats stored on this machine, not ChatGPT web conversations.

Steps to reproduce

1. Open a local Codex project containing several existing chats.
2. Wait for the current chat to be fully loaded.
3. Select another existing chat in the same project.
4. Observe an approximately 10-second wait before its history becomes usable.
5. Repeat with other chats.

Expected: switching to a local chat should take less than one second, as it did previously.

Actual: each switch takes approximately 10 seconds.

Sanitized local diagnostics

• Local session store: 785 JSONL session files, approximately 4.74 GiB total.
• Largest session: approximately 591.7 MiB.
• Thirteen session files are larger than 50 MiB.
• Recent actively read sessions include files of approximately 87.4, 54.4, and 44.7 MiB.
• Local log database: approximately 806 MiB.
• System volume reports healthy and has approximately 203 GB free.

Desktop logs suggest the visible delay is not simply raw transcript retrieval:

• Recent thread/read requests are generally completed in tens to hundreds of milliseconds.
• An approximately 54.4 MiB session averaged 22 ms per logged thread/read, with a maximum of 119 ms.
• An approximately 44.7 MiB session averaged 51 ms, with a maximum of 323 ms.
• An approximately 87.4 MiB session averaged 261 ms, with a maximum of 1,006 ms.
• The largest recent logged thread/read was approximately 2.02 seconds during application startup, still substantially shorter than the approximately 10-second user-visible delay.

A live process snapshot during active use showed a large number of Electron renderer processes, with an overall application footprint of roughly 3.5 GiB. The largest renderer was approximately 714 MiB and the local app-server approximately 321 MiB. This snapshot is not proof of causation, but it is consistent with the delay occurring in Desktop thread activation, hydration, rendering, or retained UI state after the local history response has arrived.

This appears closely related to:

• #29187 — Codex Desktop thread switching is consistently slow on Windows
• #29590 — Codex Desktop becomes unresponsive when opening previous conversations; thread history loading appears too eager
• #18693 — Desktop performance collapses with very large local conversation histories
• #21134 — Long active threads, renderer memory, and local log churn

I can provide a short screen recording, a precise reproduction timestamp, and a narrowly scoped sanitized log excerpt. I will not upload raw session transcripts or complete local databases because they may contain source code, prompts, local paths, and other sensitive information.

Additional current-build reproduction from a Windows 11 Pro x64 system, together with earlier controlled observations from the same machine.

Environment

• Codex/ChatGPT Desktop package: OpenAI.Codex 26.721.4979.0 x64
• OS: Windows 11 Pro, 10.0.26200 x64
• RAM: approximately 31.9 GiB
• GPU: NVIDIA GeForce RTX 3070 Ti
• NVIDIA driver: 32.0.16.1088

User-visible symptom

While Codex Desktop is open, the machine experiences severe brief system-wide stutters during normal work. The most noticeable trigger is switching between tasks in the sidebar: mouse movement stops and the desktop/UI appears frozen for roughly a couple of seconds before recovering.

This is not being reported as model/network latency. The pointer and unrelated Windows UI are affected during the stall.

Earlier controlled observations from the same machine

A controlled investigation on July 17, on an earlier Desktop build, produced several relevant observations:

• Stutters continued while Codex was minimized, stopped after fully exiting Codex, and returned intermittently after restarting it.
• After one restart, Codex created 38 descendant processes within six minutes. The Desktop process tree reached approximately 3.1 GiB of private memory, with codex.exe itself at approximately 1.17 GiB. A separate five-minute monitor observed as many as 80 descendants before the full exit.
• Peak aggregate Codex CPU usage during that monitor was only 6.6% of total CPU and DPC reached at most 1%, so the stutters did not look like simple CPU saturation.
• A 202-second WPR General Profile trace recorded regular ChatGPT.exe renderer MsgCheck Delay events of approximately 500–657 ms. Typing in Microsoft Word remained responsive at the same time. These renderer delays did not coincide with the marked system-wide cursor freezes, so they are reported as a separate UI-responsiveness signal rather than proof of the freeze root cause.
• Opening Codex Pet appeared to increase the likelihood of stuttering. In a controlled comparison where a freeze did not reproduce, average dwm.exe GPU utilization increased from approximately 1.7% to 4.7%, with the peak increasing from 16% to 42%, while CPU, DPC, and IRQ activity did not increase. This is correlation only.

Sanitized current-build process snapshot

A read-only snapshot taken during ordinary active use, with this diagnostic task running, showed the following full process tree under the main ChatGPT.exe process:

• 163 live processes
• approximately 6.62 GiB aggregate private memory
• approximately 8.83 GiB aggregate working set
• 34,804 handles
• 1,739 threads

Largest process families:

• node.exe: 69 processes, approximately 3.69 GiB aggregate private memory
• ChatGPT.exe: 12 processes, approximately 1.77 GiB aggregate private memory
• python.exe: 12 processes, approximately 561 MiB aggregate private memory
• cmd.exe: 45 processes, approximately 235 MiB aggregate private memory
• node_repl.exe: 6 processes
• serena.exe: 6 processes

Important boundary: this was an active-use snapshot, not an idle baseline, and the process counts are correlation rather than proof of the immediate freeze cause.

There were zero live taskkill.exe processes in the app tree during this snapshot. That distinguishes this reproduction from the accumulated taskkill/WMI storm in #33776, although retained tool/plugin/runtime fanout may still amplify the system impact.

Additional negative checks and local state

• No matching Codex/ChatGPT Application Hang event ID 1002 was found in the previous 14 days.
• WSL_DISTRO_NAME was absent from the process and user environment.
• The current workspace root does not contain a .git directory, so this reproduction is not explained by an empty/malformed workspace-root .git loop.
• Active local log database: logs_2.sqlite = 739,844,096 bytes; WAL = 11,564,872 bytes. File size alone does not prove active write pressure, so this is included only as retained-state context.

Taken together, the current task-switch reproduction and the earlier minimized-versus-fully-closed A/B observation suggest that Desktop lifetime and retained runtime state are relevant. The large process fanout, renderer delays, and DWM behavior may be amplification signals, but none is established as the immediate root cause. A narrowly scoped trace during the exact current-build task-switch stall is still needed to assign root cause.

I can provide a precise reproduction timestamp, a sanitized summary of the earlier WPR analysis, and a narrowly scoped new performance trace if maintainers want them. Raw transcripts, complete logs, local databases, and the full historical ETL will not be uploaded publicly because they may contain private project or process metadata.

Escalation request — 45 days without a maintainer update

This regression remains reproducible today on Windows with the currently installed Microsoft Store package, OpenAI.Codex 26.727.6591.0.

Issue #29187 was opened on June 20, 2026. As of August 4, 2026—45 days later—it has no visible maintainer response, assignee, milestone, supported workaround, fix build, or ETA. The problem has persisted through repeated application updates, full application restarts, and Windows reboots.

Switching between existing local Codex tasks still takes approximately 10 seconds, where it was previously nearly instantaneous. This materially affects daily paid use because I switch tasks constantly. The sanitized diagnostics and privacy boundaries from my earlier report remain applicable: https://github.com/openai/codex/issues/29187#issuecomment-5109581194

There are now several overlapping Windows Desktop performance reports, but no publicly identified canonical tracker or engineering owner. Could someone from the Codex team please confirm:

1. Whether this regression is actively being investigated
2. Which issue is the canonical tracker
3. Whether there is a supported workaround
4. Which release is expected to contain a fix, if known
5. What additional narrowly scoped, sanitized diagnostic would be useful

I will not post raw task transcripts or complete local databases because they may contain private source code and working-session information. I can provide a short screen recording, precise reproduction timestamps, and narrowly scoped sanitized logs through an appropriate private channel.