[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<br>renderer (ChatGPT.exe) allocates unboundedly, stops responding \~20 s after the window appears, peaks<br>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<br>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.<br>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<br>and same data. The Store payload (ChatGPT.exe, chrome.dll, 151.0.7922.76.manifest) is all stamped<br>2026-08-06 22:44–22:45, and the first failure was at 22:44 that evening. Still reproducing 4 days later;<br>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:

<!-- linear:table-colwidths:266,266,266 -->
| 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<br>1,011 MB → 3,215 MB inside a single second. Across 8 instrumented runs the freeze consistently lands at<br>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,<br>experimentalFeature/*, model/list, plugin/list, permissionProfile/list, thread/list,<br>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.

<!-- linear:table-colwidths:266,266,266 -->
| 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<br>disk, the renderer still climbs to \~3.8 GB and hangs on the same timeline. Consistent with openai/codex#27175<br>("even with empty sessions"), but obtained non-destructively — every file was moved to a holding<br>directory and restored afterwards, verified byte-for-byte.

Note: per-plugin enabled = false stops skills loading but leaves the plugin/marketplace subsystem<br>active (plugin/list, marketplace/add, manifest scans continue; span still reports<br>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<br>produces a different early failure — no window is created and a core spins at 100% with the app-server<br>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<br>first_user_message length in every row. Observed max 176,600 chars, mean 7,454 across 660 rows,<br>so thread/list hands the renderer roughly 13.6 MB of title/preview text. It isn't the cause of this hang<br>(it reproduces at zero threads), but it lines up with the "bound the active list payload sent to the<br>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<br>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:<br>Store-distributed MSIX has no version pinning, uninstall + reinstall refetches the identical build, and<br>the installer URLs embedded in the CLI (apps.microsoft.com/detail/9plm9xgg6vks1,<br>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.