›_ Codex Issues
Codex Issues / #38713

[Windows][Desktop 26.810.6296.0] Opening already-running Codex makes ChatGPT.exe MAIN burn ~8.5 CPU-sec/6s and ~1GB until full restart

Open 💬 3 comments Opened Aug 15, 2026 by Isajunsei
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Windows Store / AppX package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0

ChatGPT.exe file version: 151.0.7922.137

Installed location: C:\Program Files\WindowsApps\OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

The in-app “About Codex” dialog string was not captured during the live measurements. The package version above is from Get-AppxPackage OpenAI.Codex on the affected machine.

What subscription do you have?

Not exposed during diagnostics. Please treat as unknown rather than guessed.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Windows 11 Home, build 26200.9168

What issue are you seeing?

Summary

On Windows, opening Codex Desktop (showing the window of an already-running packaged ChatGPT.exe) makes the main process enter a sustained CPU runaway. The whole PC stutters until the entire Codex process tree is stopped and relaunched.

This is not a one-time Store-update leftover. It comes back every time the window is opened.

Two separate classes were measured on the same machine the same day. Cleaning class A does not stop class B.

Class A — leftover Store package under WindowsApps\Deleted (side channel)

After a Store/app update, the old tree can sit in:

C:\Program Files\WindowsApps\Deleted\OpenAI.Codex_<old>_*

AppX Operational event 471 then retries the delete and fails, e.g. resources.pak with 0x12C. The same 471 class also hit non-Codex leftovers on this PC (Microsoft.WindowsAppRuntime_*, Microsoft.DesktopAppInstaller_*, and later a Claude leftover). Periodic delete retries correlate with whole-PC stutter.

Elevated wipe of all Deleted\* dirs → Deleted count 0, no 471 for hours.

Class A being empty does not stop the stutter below.

Class B — packaged ChatGPT.exe MAIN thrash on window open (the actual remaining bug)

Main process = packaged ChatGPT.exe whose command line has no --type= (not gpu / renderer / network / crashpad).

Measured shape, local time JST, 2026-08-15:

| When | MAIN PID | CPU in sample | Working set | Notes |
| --- | --- | --- | --- | --- |
| Morning, after Deleted was already empty | (earlier PID) | ~4.3 CPU-sec / 3 wall-sec | ~1.2 GB | Whole-PC lag. Full tree restart calmed it. |
| 13:40, after opening Codex | 34880 | 8.7 CPU-sec / 6 wall-sec | ~1026 MB | Children quiet (gpu 0.08s, renderer 0.8s, codex.exe 0.08s). Chrome 0.77s / Logi 0.17s in the same window — not the stutter. |
| 13:41–15:40, process left running (window not in use / tray-like) | 44988 | 0.02–0.09 CPU-sec / 6s every 5 min | ~300–317 MB | Looks healthy. |
| 15:43, immediately after opening Codex again | 44988 | 8.5 CPU-sec / 6 wall-sec | 918 MB | Same PID as the idle period. Opening the window flipped it. |
| 15:45:09 automatic sample | 44988 | 8.36 CPU-sec / 6s | 1004 MB | Same runaway still held. |
| 15:45:18 after full stop + relaunch | 55996 | idle | 323 MB | Relaunch observed. New MAIN start 15:45:17. |

Command line of the hot process (no --type=):

"C:\Program Files\WindowsApps\OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe"

AppX 471 in the 2 hours around the 15:43 open: none. Deleted was not the cause of that spike.

Why local workarounds are not a fix

We already tried everything we can do outside the app:

  1. Delete WindowsApps\Deleted leftovers (Codex and non-Codex). This stops class A only.
  2. One-shot kill + relaunch of the Codex tree when MAIN ≥ 5.0 CPU-sec / 6s. This temporarily returns the machine to normal. It does not prevent the next open from doing the same thing.
  3. A 5-minute poll of an already-running instance reports ok (0.03 CPU-sec, 311 MB) two minutes before the user opens the window and MAIN jumps to 8.5 CPU-sec / ~1 GB. The open event itself is what flips the process.
  4. A 20-minute cooldown after a restart means the next open inside that window is unhealed.
  5. An earlier “keep killing ChatGPT and block relaunch until AppX cleanup finishes” workaround made Codex look unstartable. Please do not recommend that class of fix. Relaunch must never be blocked.

So: we can mop the floor after it floods. We cannot stop the tap. This needs a product fix.

What steps can reproduce the bug?

Reproduced multiple times on 2026-08-15, package 26.810.6296.0, no extra 471 activity.

  1. Install / leave Codex Desktop running as the Microsoft Store app OpenAI.Codex (process tree rooted at packaged ChatGPT.exe).
  2. Leave it running in the background / tray so MAIN is the no---type= process. Optional check: MAIN is ~300 MB and uses ~0.03 CPU-sec over 6 seconds.
  3. Open the Codex window (user click / restore / launch the app id OpenAI.Codex_2p2nqsd0c76g0!App while the process is already alive).
  4. Within seconds the whole desktop stutters.
  5. Sample only the MAIN ChatGPT.exe (command line must not contain --type=). Observe ~8.3–8.7 CPU-seconds in a 6-second wall sample and working set ~0.9–1.0+ GB. Child --type= processes stay comparatively quiet.
  6. Fully stop the packaged tree and relaunch shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App. Stutter stops. MAIN returns to ~300 MB.
  7. Repeat step 3. The runaway returns.

Not required to reproduce class B:

  • A live WindowsApps\Deleted leftover
  • A current AppX 471/493 storm
  • A long agent turn
  • Multiple extra Codex windows (the 13:40 / 15:43 hits were the existing single tree)

Session / token / context-window IDs were not captured; this is a host-process failure, not a single-thread prompt failure.

What is the expected behavior?

Opening an already-running Codex Desktop window should not pin a logical core on the Electron/Chromium main process or inflate it from ~300 MB to ~1 GB.

If a Store update leaves an old package under WindowsApps\Deleted, AppX should be able to delete it without a 471 retry loop, and that leftover should not be required to explain MAIN CPU after Deleted is empty.

Restarting the app should not be the only way to get a usable desktop again.

Additional information

Same-day timeline (JST, 2026-08-15) — complete local history

Morning — Store update residue + first MAIN runaway

  • Current package became OpenAI.Codex_26.810.6296.0.
  • Old package stuck at Deleted\OpenAI.Codex_26.810.4967.0_....
  • AppX Operational 471 on resources.pak (0x12C).
  • A local cleanup tool that stopped all Codex processes and blocked auto-relaunch for up to ~20 minutes made the app appear not to start. That design was abandoned. Do not ship anything like it.
  • After Codex Deleted residue was removed, stutter returned. Remaining Deleted dirs were Microsoft.WindowsAppRuntime.1.8_* and Microsoft.DesktopAppInstaller_* (471 0x5 about every 6 minutes).
  • Elevated wipe of those dirs → Deleted entries = 0, subsequent 471 = 0.
  • User still felt lag. MAIN ChatGPT.exe ~4.3 CPU-sec / 3 wall-sec, ~1.2 GB WS. Full tree restart → calm.

Afternoon — “I opened Codex and it stuttered again”

  • 13:40: MAIN PID 34880, 8.7 CPU-sec / 6s, WS 1026 MB. 471 last 2h = 0. Deleted empty.
  • Same 6-second window, other processes: chrome 0.77s, Logi agent 0.17s. Not the cause.
  • One-shot stop + relaunch via shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App → MAIN ~0.22 CPU-sec / 7s. User confirmed the stutter was gone until the next open.

Later the same afternoon — idle is fine, open is not

  • New MAIN PID 44988 started 13:41:53.
  • 13:50 through 15:40: automatic 6-second samples every 5 minutes, all reason=ok, mainDelta 0.00–0.09, WS 300–317 MB.
  • User opened Codex again. Immediate whole-PC stutter.
  • 15:43 live sample: PID 44988 8.5 CPU-sec / 6s, WS 918 MB. 471 last 2h still 0.
  • 15:45:02 scheduled sample: THRASH CHECK | reason=main-cpu mainDelta=8.36 sampleSec=6 pid=44988 wsMb=1004 then one-shot stop/relaunch, observed=True.
  • New MAIN PID 55996 started 15:45:17, WS 323 MB.

What this rules out

  • Not “just AppX Deleted leftovers.” Those were gone for hours.
  • Not chrome / Logitech / other desktop agents. Measured in the same sample and quiet.
  • Not a renderer-only cost. The hot PID is MAIN (no --type=). GPU/renderer/network/codex.exe were not the 8.5s burn.
  • Not “the process is always hot.” The same PID was healthy at 311 MB / 0.03 CPU-sec at 15:40:09 and pathological at 15:43 after the window was opened.
  • Not fixed by restarting once. The next open repeats it.

Related issues (searched before filing)

These are in the same Windows Desktop performance cluster. None of them is this exact trigger + this exact package + this MAIN-only open flip:

  • #38640 — ChatGPT.exe persistent CPU / ~1 GB/s process-read until restart (26.810.4967.0). Closest cousin. Ours is newer (26.810.6296.0) and flips on window open of an already-idle MAIN, not only after a long degraded session.
  • #38518 — opening/switching conversations can start a 350–800 MiB/s read loop (26.810.4967.0).
  • #38702 — MAIN 1.1–1.5 GB/s read I/O after hours idle (26.810.4967.0).
  • #38698 — intermittent system-wide stutter; restarting Codex restores responsiveness.
  • #38710 — active thread + GPU/DWM load (26.810.4967.0).
  • #35191 — generic “Desktop Bad performance” on Darwin, not this Windows MAIN measurement.

Happy to attach a sanitized process list, the 6-second before/after samples, or AppX 471 excerpts if useful. I can also re-run with process I/O counters on the next open if you want the #38640-style read-rate numbers on 26.810.6296.0.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38710
  • #38711
  • #38659
  • #38698

Powered by Codex Action

rotate4all · 13 days ago

I can confirm a very similar failure signature on a second Windows system.

The trigger is not identical—on my machine it appears during concurrent task activity or task switching, rather than reliably every time the window is opened—but the resulting MAIN-process runaway and recovery behavior closely match this report.

Environment

  • Windows 11 25H2, build 26200.8875
  • Codex AppX package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
  • ChatGPT.exe file/product version: 151.0.7922.137
  • CPU: Intel Core i7-12700, 20 logical processors
  • GPU: NVIDIA GeForce RTX 5070, driver 610.88
  • Primary display: 1920×1080 at approximately 240 Hz

Although my AppX package is older than the reporter's 26.810.6296.0, both packages contain the same ChatGPT.exe version: 151.0.7922.137.

A/B result

Closing Codex immediately restores smooth desktop operation.

This does not require restarting Explorer, DWM, Windows, or the NVIDIA driver. Explorer windows that were already open become smooth as soon as the complete Codex Desktop process tree exits.

Relaunching Codex returns the system to normal, at least temporarily.

After one clean Codex restart:

| State | MAIN PID | CPU sample | Working set |
| --- | ---: | ---: | ---: |
| Healthy after restart | 14120 | 0.109 CPU-sec / 5s | 345 MB |
| Fault active, same PID | 14120 | 10.906 CPU-sec / 8.005s | 1009 MB |
| Fault still active two minutes later | 14120 | 13.891 CPU-sec / 10.017s | 940 MB; private bytes 1049 MB |

The hot PID is the packaged ChatGPT.exe with no --type= argument:

"C:\Program Files\WindowsApps\OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe"

The second sample represents approximately 1.36 logical cores continuously; the later sample was approximately 1.39 logical cores.

The child processes were comparatively quiet in the same eight-second sample:

| Process role | CPU sample |
| --- | ---: |
| MAIN, no --type= | 10.906s |
| Hottest renderer | 0.750s |
| GPU process | 0.188s |
| codex.exe app-server | 0.172s |
| Other renderers | 0.000–0.047s |

This strongly points to the Electron/Chromium MAIN process, not the renderer, GPU subprocess, or Codex agent backend.

Symptoms

While MAIN is hot:

  • The mouse cursor becomes visibly jerky across most of the desktop.
  • Dragging Explorer or Codex windows resembles low-frame-rate stop-motion.
  • Explorer windows are affected even though Explorer itself has not restarted.
  • Task Manager remains conspicuously smooth, including while dragging its window.
  • Minimizing Codex to the taskbar or tray does not stop the stutter.
  • Lowering only the hot MAIN process to Below Normal priority did not fix it.
  • Fully exiting Codex fixes it immediately.

Trigger difference

My latest controlled sequence was:

  1. Fully restart Codex.
  2. Confirm that desktop movement is smooth.
  3. Measure MAIN at 0.109 CPU-sec / 5s, approximately 345 MB.
  4. Continue work with another Codex task actively streaming in parallel.
  5. The system-wide stutter returns.
  6. Measure the same MAIN PID at approximately 1.36–1.39 logical cores and approximately 1 GB.
  7. Child renderer/GPU/app-server processes remain comparatively quiet.

Earlier occurrences sometimes appeared after sleep/resume or after switching to a particular long Codex task, but not necessarily immediately. The clean restart → healthy MAIN → concurrent activity → same-PID MAIN runaway transition is the strongest reproduction so far.

This suggests there may be more than one action capable of flipping MAIN into the same pathological state:

  • Restoring or opening an already-running window, as reported here
  • Switching between task streams
  • Processing concurrent active tasks
  • Possibly accumulated task/UI state over time

Other causes excluded in this reproduction

  • The secondary HDMI display was physically unplugged.
  • Only the 240 Hz DisplayPort monitor was active.
  • MSI Afterburner and RTSS were stopped.
  • RTSS hooks were verified absent from Explorer and the relevant Codex rendering path.
  • GPU subprocess load was only about 2.3% of one core.
  • NVIDIA GPU utilization was otherwise low.
  • No contemporaneous nvlddmkm reset, WHEA error, DWM crash, or application hang was found.
  • DPC/ISR activity was low; no kernel or USB interrupt storm was observed.
  • Restarting Explorer did not help during an earlier occurrence.
  • Restarting the NVIDIA driver was not required for recovery.

Logs and trace evidence

During affected periods, Codex logs contain repeated:

ResizeObserver loop completed with undelivered notifications.

They also contain bursts of:

Received turn/started for unknown conversation
Received turn/completed for unknown conversation

Events from two concurrent task streams were being routed through the same desktop host, sometimes to both the primary renderer and a hidden avatarOverlay renderer.

However, some ResizeObserver messages also occur while the app is healthy, so I do not consider that message alone proof of the root cause. It may instead identify UI activity accompanying the runaway.

I also captured a 15-second WPR trace during an earlier occurrence using:

  • GeneralProfile.light
  • GPU.light
  • DesktopComposition.light
  • File mode

The trace contains 3,071,244 events with zero lost events. During that capture the Codex MAIN process accumulated approximately 24.9 CPU-seconds over roughly 17.6 seconds, consistent with the later live measurements.

The ETL is approximately 385 MB and is available if maintainers want it.

Assessment

This appears to confirm the same underlying Class B failure described in this issue:

An already-running packaged Codex instance can transition from a healthy approximately 300–350 MB MAIN process into a sustained approximately 1 GB, 1.3–1.5-core MAIN-process runaway. The entire desktop becomes choppy, while renderer, GPU, and app-server children remain relatively quiet. Only fully restarting the Codex process tree reliably resets the condition.

The fact that both 26.810.4967.0 and 26.810.6296.0 carry ChatGPT.exe version 151.0.7922.137 may be relevant.

chunshulimao · 13 days ago

Independent reproduction on the same Windows build OpenAI.Codex_26.810.6296.0 (Intel i7-14650HX, 24 logical processors, 32 GB RAM).

Symptoms:

  • No active Codex tasks and no awakened pet/overlay, yet the desktop and mouse visibly stutter.
  • Fully restarting Codex restores responsiveness for only about 30 minutes, then the lag returns.
  • The hot process is the packaged main ChatGPT.exe with no --type=.
  • Fresh samples: about 133–145% of one logical core (roughly 5–6% overall on 24 logical processors), approximately 0.6–1.2 GB memory, and 69–70 threads.
  • Child/GPU load is comparatively low: Codex GPU process ~1.7%, DWM ~1.1%; total system RAM ~56%; no display-driver reset or app-hang events were found.

Day-over-day comparison from the app's local logs on the same machine:

  • thread/turns/list: 110.9/hour on Aug 14 → 427.8/hour on Aug 15 (~3.9×)
  • Received ... for unknown conversation: 3.2/hour → 206.7/hour (~65×)
  • ResizeObserver loop completed...: 357.3/hour → 276.7/hour, so that message existed before the update and does not appear to be the newly introduced trigger.

This suggests an Electron-main conversation/history synchronization or notification-routing loop that continues while the UI is idle. This independent reproduction matches the MAIN-only CPU runaway described here and adds an idle/no-active-task case plus day-over-day event-rate evidence.

No chat content, project files, or full logs are included in this report.