[Windows] Codex Desktop renderer allocates to ~4.7 GB and hangs ~20s after launch on 26.803.5235.0 - reproduces with zero conversations

Summary

Since the Store update on 2026-08-06, Codex Desktop is unusable on Windows 11. On every launch the
renderer (ChatGPT.exe) allocates unboundedly, stops responding ~20 s after the window appears, peaks
around 4.7–4.8 GB, and is killed by Windows.

The backend is healthy. The Rust app-server completes startup in ~10 s with zero errors and then goes
idle. The renderer consumes ~4.6 GB while making no further app-server requests at all.

It also reproduces with zero conversations — empty threads table and an empty sessions/ directory.
That should make this cheap to reproduce on a clean profile.

Environment

• Windows 11 Pro 26200 (x64)
• Codex Desktop: MSIX Store package OpenAI.Codex 26.803.5235.0
• Electron shell: ChatGPT.exe 151.0.7922.76
• Codex CLI / app-server: 0.147.0-alpha.6.5
• Auth: ChatGPT

Last known-good: CLI 0.146.0-alpha.9.2, which ran 7-, 12.5- and 80-hour sessions on the same machine
and same data. The Store payload (ChatGPT.exe, chrome.dll, 151.0.7922.76.manifest) is all stamped
2026-08-06 22:44–22:45, and the first failure was at 22:44 that evening. Still reproducing 4 days later;
no Store update has shipped since.

Windows record

Event ID 1002 (Application)
The program ChatGPT.exe version 151.0.7922.76 stopped interacting with Windows and was closed.
Event Name: MoAppHang

Measured behaviour

Sampled every 1.5 s, t=0 at UI process start. Representative run:

t	Working set	Responding
0 s	103 MB	yes
11 s	1,133 MB	yes
20 s	3,018 MB	no
24 s	4,221 MB	no
85 s	peak 4,704 MB	process dead

Allocation runs at roughly 210–300 MB/s through the transition; one sample pair caught
1,011 MB → 3,215 MB inside a single second. Across 8 instrumented runs the freeze consistently lands at
19–23 s after UI start, peaking 3.8–4.8 GB.

No backend traffic during the blowup

From the app-server's own log DB (~/.codex/logs_2.sqlite):

• Last request the UI issued: app/read at +10.2 s
• Nothing after that from the renderer
• App-server answered everything and went idle with 0 ERROR rows

Requests seen, in order: initialize, config/read, getAuthStatus, account/read,
experimentalFeature/*, model/list, plugin/list, permissionProfile/list, thread/list,
externalAgentConfig/import/readHistories, marketplace/add, skills/list, app/list, app/read.

No thread/resume, no thread/read, no rollout load, in any run.

What was ruled out

Each of these was verified to have actually taken effect, not just attempted.

Hypothesis	Test	Result
Corrupt local state	codex doctor; SQLite quick_check on all 4 DBs	0 fail, all integrity ok
Large session files	Verified a 28.45 MB / 1,366-line session, zero bad lines	intact, and never loaded
Restored editor tab	Removed thread-tab-routes-v1 entry (pointed at a deleted file)	no change
Stale caches / disk bloat	Cleared 364 MB of orphaned marketplace staging; VACUUMed log DB	no change
Plugin-provided skills	All 20 [plugins."…"] enabled = false; confirmed skills::loader warnings 8 → 0	still crashes
Renderer profile	Inspected web storage	only 0.2 MB / 8 files; no IndexedDB or service workers
GPU / compositing	--disable-gpu (software rasterizer retained); confirmed applied via unchanged GrShaderCache mtime	still crashes — unresponsive at +23 s / 3,463 MB
Thread-list volume	threads table 703 → 20 rows, 683 rollout files moved aside	still crashes — +23 s / 3,313 MB
Any conversation at all	threads table emptied to 0 rows, all 703 rollout files moved out of sessions/	still crashes — 1,136 MB at +14 s, unresponsive at +20 s / 2,821 MB

The zero-conversation result is the important one: with no threads in the database and no session files on
disk, the renderer still climbs to ~3.8 GB and hangs on the same timeline. Consistent with openai/codex#27175
("even with empty sessions"), but obtained non-destructively — every file was moved to a holding
directory and restored afterwards, verified byte-for-byte.

Note: per-plugin enabled = false stops skills loading but leaves the plugin/marketplace subsystem
active (plugin/list, marketplace/add, manifest scans continue; span still reports
plugins_enabled=true). So the plugin subsystem is not fully excluded.

Also note: --disable-gpu together with --disable-software-rasterizer leaves no rasterizer at all and
produces a different early failure — no window is created and a core spins at 100% with the app-server
never spawning. Not a valid test of this bug.

Possibly related, though not the cause here

The threads table stores the entire first user message in the title column — title length equals
first_user_message length in every row. Observed max 176,600 chars, mean 7,454 across 660 rows,
so thread/list hands the renderer roughly 13.6 MB of title/preview text. It isn't the cause of this hang
(it reproduces at zero threads), but it lines up with the "bound the active list payload sent to the
renderer" suggestion in openai/codex#26362.

Reproduction

1. Launch Codex Desktop on 26.803.5235.0 / ChatGPT.exe 151.0.7922.76.
2. Watch the ChatGPT.exe process with the largest working set.
3. It crosses 1 GB by ~11 s, stops responding by ~20 s, peaks ~4.7 GB, and is killed.

UI appearance varies run to run — sometimes the conversation list paints before the freeze, sometimes the
window never paints at all. The failure is not gated on a particular render stage.

Impact

GUI fully unusable. The CLI works normally and is the current workaround. No rollback path exists:
Store-distributed MSIX has no version pinning, uninstall + reinstall refetches the identical build, and
the installer URLs embedded in the CLI (apps.microsoft.com/detail/9plm9xgg6vks1,
get.microsoft.com/installer/download/9PLM9XGG6VKS) both point back to the Store. See also openai/codex#26914.

Possibly related: openai/codex#26362, openai/codex#33483, openai/codex#27175, openai/codex#26401.

Start by reproducing the issue with an empty threads table and no session files, then trace the Electron renderer after the final app/read request at about +10.2 seconds. Compare the renderer behavior with the last known-good CLI version 0.146.0-alpha.9.2; done means ChatGPT.exe no longer shows runaway allocation or hangs around 20 seconds on the specified Windows build.