[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

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.

Start by reproducing the packaged OpenAI.Codex AppX flow: measure the MAIN ChatGPT.exe before and after opening an already-running window, while confirming child processes remain comparatively quiet. Done means opening the existing window no longer causes sustained MAIN CPU and roughly 1 GB memory growth, and a full restart is not required to restore responsiveness.