[Windows][Desktop 26.810.4967.0] Opening or switching conversations can trigger a persistent 350-800 MiB/s read loop and system-wide stutter

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

• #38506

Powered by Codex Action

Additional Windows desktop data point on the same build.

Environment:

• Codex desktop app: 26.810.4967.0 x64 MSIX
• Windows: Microsoft Windows NT 10.0.22631.0 x64
• Hybrid GPU laptop: NVIDIA RTX 4070 Laptop GPU + AMD Radeon 610M driving the internal display (2560x1600 @ 165Hz)

Observed behavior:

• After a full app restart or a lightweight cache reset, Windows/Codex is initially smooth.
• After using the long Codex task for a while, system-wide mouse/UI stutter returns. It is visible outside Codex too.
• Fully restarting Codex clears it temporarily.
• Moving the Codex/ChatGPT Windows Graphics preference to power saving/iGPU kept ChatGPT.exe off the NVIDIA GPU, but the issue still recurred. During the bad state, nvidia-smi did not list ChatGPT.exe; the NVIDIA GPU was idle/low-power.

Sanitized 30-second monitor samples after the temporary cache reset:

17:51:38  ChatGPT CPU delta  2.03s / 30s, DWM GPU ~19.47%, ChatGPT GPU ~10.65%
17:52:11  ChatGPT CPU delta  2.77s / 30s, DWM GPU ~21.87%, ChatGPT GPU ~9.82%
17:53:17  ChatGPT CPU delta  4.41s / 30s, DWM GPU ~24.55%, ChatGPT GPU ~8.76%
17:54:56  ChatGPT CPU delta 21.14s / 30s, alert
17:55:29  ChatGPT CPU delta 25.88s / 30s, DWM GPU ~15.71%, ChatGPT GPU ~15.06%, alert
17:56:02  ChatGPT CPU delta 26.38s / 30s, DWM GPU ~17.28%, ChatGPT GPU ~13.38%, alert

Process attribution in the bad state:

• The top-level/main ChatGPT.exe process, with no --type=... argument, consumed most of the CPU: about 20.83s, 24.30s, and 24.88s CPU time per 30-second window in consecutive alert samples.
• The --type=gpu-process and --type=renderer children were secondary.
• DPC/Interrupt activity stayed low, memory was not pressured, and no display-driver error stood out in this capture.

Cache/workaround notes:

• A lightweight reset of Chromium/Electron-style caches (GPUCache, ShaderCache, Code Cache, Service Worker cache, etc.) restored smoothness temporarily, but the stutter returned after more use.
• This local capture did not show the chrome_native_host_cache_reconcile_failed / native-host retry-loop signature mentioned in #38510, so this looks separate from that issue.
• I did not attach raw logs because they include local paths/session metadata, but I can provide more sanitized counters if useful.

Difference from the original report here: I did not capture the 350-700 MiB/s read loop during this run. The dominant signal in this capture was instead a persistent main-process CPU loop combined with DWM/UI composition load. The user-visible symptom, build, long-task/session trigger, and restart workaround match this issue closely.

Update: reproduced on 26.810.6296.0 and isolated to the runtime hashing loop

I can now reproduce the same persistent read loop on Windows desktop 26.810.6296.0 and narrow the I/O source considerably.

• The affected process is still the top-level/main ChatGPT.exe process (no --type=... argument). The codex.exe backend and renderer/GPU children are not the source of the high read rate.
• Repeated file-position sampling showed active rereads of both sides of the plugin app-server runtime: the bundled/runtime-source codex.exe and %USERPROFILE%\.codex\plugins\.plugin-appserver\codex.exe (about 281.5 MiB each), plus both copies of codex-code-mode-host.exe (about 56.6 MiB each). During the same samples I did not observe active reads of session JSONL files, workspace files, or the small Codex SQLite databases.
• In the packaged bundle, the chrome-plugin-app-server-runtime file-equivalence check hashes each full file using createHash("sha256").update(await fs.promises.readFile(path)).digest("hex"). The codex.exe pair alone therefore reads about 563 MiB per validation; including the two code-mode-host copies brings the observed minimum to about 676 MiB per pass, before other helpers/resources. This matches the hotspot independently reported in #38547.
• The source and destination runtime files have identical sizes and modification times, and the loop produces negligible corresponding writes. This makes a corrupt-file/repeated-copy explanation unlikely; the expensive validation itself appears to be repeating or overlapping.

Controlled reversible A/B tests on the one persistent hot thread in the main process:

• 2.2-second suspension: 489.61 MiB/s before -> 0 MiB/s while suspended -> 542.63 MiB/s after resume.
• 60-second suspension: 627.53 MiB/s before -> 0 MiB/s for the suspended interval -> 669.44 MiB/s after resume.
• The main process remained alive, the thread's suspend count was restored cleanly, and the independent recovery watchdog exited. No process was terminated.

This strongly indicates that the main event/hash-control thread is continuously driving the runtime comparison. Restarting the app clears the active loop, but opening/navigating the app can trigger it again. The newer-build symptoms are also consistent with #38713.

Suggested product-side fixes:

• single-flight/deduplicate runtime preparation and equivalence checks;
• cache a successful validation by runtime version plus path/size/mtime instead of rehashing unchanged binaries;
• cancel stale validation work after navigation/state changes;
• avoid loading hundreds-of-megabytes binaries into full buffers for every check, and limit validation concurrency.

No transcript content, account details, local usernames, session/task identifiers, raw logs, screenshots, or machine-specific absolute paths are included in this update.

Additional recurrence: main-process read loop reproduced with zero node_repl workers

Another Windows 11 recurrence on Desktop 26.810.6296.0 separates the main-process loop from the retained-worker issue:

• node_repl.exe count was 0 and its config block was not active at the start of the capture.
• The top-level ChatGPT.exe sustained 143% of one logical core and 825,102,238 bytes/sec logical read I/O (about 787 MiB/s).
• The renderer/GPU processes were far below that rate; the top-level process was the clear source.
• After disabling the bundled chrome, browser, and computer-use plugins and fully restarting Codex, the new top-level process measured 0 MiB/s reads and 0% CPU in the same formatted performance counters.

This confirms that the main runtime-validation/read loop can independently cause whole-system stutter even when no node_repl workers are present. The restart clears the active loop; disabling those three plugins is being used as a mitigation while monitoring for recurrence.

No session content, account details, usernames, local paths, or raw logs are attached.

https://github.com/openai/codex/issues/38716#issuecomment-5302760473

Additional independent Windows reproduction on the same Codex Desktop build, with a cache-resident variation of the persistent main-process read loop.

Environment / scope:

• Codex Desktop: 26.810.4967.0 x64 Store build
• Windows 11 Pro 10.0.26200
• This was the second occurrence on the same machine; the second recurrence happened without WoW or another obvious heavy foreground workload.
• No raw logs, transcript content, local usernames/paths, account data, project names, screenshots, or session identifiers are included here.

Read-only live capture while the system-wide stutter was active (59.5 s, 120 samples at 0.5 s cadence):

• Top-level/main ChatGPT.exe process (no --type=...) sustained 1,104.76 MB/s logical reads for the full capture.
• Total logical data read by that process: 65,735 MB (~64.2 GB) in 59.5 s.
• Every measured interval remained above 500 MB/s.
• Physical disk read during the same window averaged only 0.09 MB/s, with disk 99.2% idle and queue length 0.
• The same ChatGPT.exe process generated 218,418 page faults/sec, all soft in this process (0 hard faults), about 42% of the machine-wide fault load. The next busiest process was ~727 faults/sec.
• Its working set oscillated from 469.6 MB to 1,262.6 MB (793.1 MB range), with a largest single 0.5 s change of 775.2 MB.
• System available-memory swing was 1,079 MB and committed-memory swing was ~1.11 GB, matching the visible RAM sawtooth observed during the stutter.

Useful negatives from the same capture:

• codex.exe backend was essentially idle (~0.01% system CPU, ~0.02 MB/s reads).
• GPU process and renderers were not the source of the loop.
• DPC averaged 0.39%, interrupt time 0.65%, processor queue length stayed 0.
• DWM was light (~0.17% system CPU).
• No WHEA errors, display-driver resets/TDRs, storage errors, resource-exhaustion events, or app hangs/crashes were present in the recent event-log window.
• A hidden layered/transparent click-through Chrome_WidgetWin_1 overlay window did exist, but its GPU/process activity was negligible, so this capture did not support the separate avatar-overlay mechanism as the cause.

A/B after fully exiting Codex Desktop:

• Exit was verified clean: no ChatGPT.exe, codex.exe, codex-code-mode-host.exe, or node_repl process remained.
• The user-visible system-wide stutter stopped essentially immediately and the 120 Hz desktop returned to normal smoothness. This same immediate recovery had also been observed during the prior independent occurrence.
• A 20-second post-exit baseline showed:
• Page faults/sec: 516,801 -> 8,046 (~64x lower)
• Cache faults/sec: 284,481 -> 1,928 (~148x lower)
• Demand-zero faults/sec: 226,967 -> 5,496 (~41x lower)
• Top logical reader: 1,104.76 MB/s (ChatGPT) -> 17.86 MB/s (SearchIndexer)
• Largest working-set swing: 793 MB -> 97 MB
• Available-memory swing: 1,079 MB -> 175 MB
• Commit dropped from ~23.08 GB to ~20.02 GB

This strongly supports the same bug class reported here: the top-level desktop ChatGPT.exe enters a persistent local-data reread / memory-churn state, while the agent backend, GPU path, physical disk, DPCs and hardware remain quiet. In this reproduction, the reread set appears to have been almost entirely resident in the Windows file cache, which explains the extremely high logical read rate with almost no physical disk activity.

I did not capture per-file handle/ETW attribution before exiting, so I am not claiming the exact file source on this machine. The signature is consistent with the plugin-runtime hashing/validation loop isolated in the later update on this issue, but that specific code path remains an inference for this reproduction rather than a direct measurement.