Repository navigation
[Windows 11][26.803.5235.0] Renderer OOM auto-reload leaves Codex stuck on loading screen while app-server tasks continue #37541
Description
Summary
Codex Desktop on Windows repeatedly crashes only the main Electron renderer after it grows to roughly 4 GiB. The top-level ChatGPT process and codex.exe app-server remain alive, so background agent work continues, but the replacement renderer can fail to restore persisted state and remains permanently on the full-window loading screen.
This is a high-impact work-loss risk: the only obvious recovery is ending the app in Task Manager, which interrupts every active local thread. The issue is still reproducible on package 26.803.5235.0.
This report adds Windows-specific evidence to #34863, #34890, and #28316.
Environment
- Product: Codex Desktop inside the ChatGPT Windows app
- Package: OpenAI.Codex 26.803.5235.0
- OS: Windows 11 Pro, build 26200, x64
- Physical RAM: 61.61 GiB
- Commit limit: 125.61 GiB
- Workload: multiple concurrent long-running Codex threads, including image/browser-heavy histories and forked conversations
Repeated crash timeline
Three renderer crashes were captured on the same day:
| Local time | Renderer evidence | App-server evidence | Recovery |
|---|---|---|---|
| 08:37:54 | Crashpad sidecar, ptype=renderer; dominant renderer had reached 3.10 GiB | app-server reached 18.90 GiB near the event | automatic renderer recovery succeeded; routes mounted after 2.754 s |
| 09:17:46 | Crashpad sidecar, ptype=renderer; dominant renderer was 4.03 GiB one minute earlier | app-server reached 14.62 GiB | persisted-state sync timed out; UI did not mount |
| 13:01:56 | Crashpad sidecar, ptype=renderer; dominant renderer was already 3.89 GiB at 12:46 | app-server reached 22.72 GiB private / 21.81 GiB working set | renderer PIDs were replaced, persisted-state sync timed out, loading screen remained |
At the third failure, the desktop main process and app-server PIDs and start times did not change. Background reasoning events continued after the renderer replacement.
Relevant desktop log sequence:
13:01:58.139 [statsig-refresh-diagnostics] React root render requested
13:02:04.203 [persisted-atom] host did not respond to sync request; continuing with legacy state only
There was no subsequent [startup][renderer] app routes mounted entry for that reload.
Windows Application/System logs contained no matching Application Error, Application Hang, WER, or resource-exhaustion event. System commit was about 57.8% at the peak with about 13.3 GiB available RAM, so this was not whole-system commit exhaustion.
Oversized image-heavy sessions
Immediately before the third crash, the app repeatedly requested histories for active rollout files sized approximately:
- 8.21 GiB
- 5.38 GiB
- 7.08 GiB
Observed request latency:
- thread/turns/list: up to 27.265 seconds
- other thread/turns/list calls: about 14.5-19.4 seconds
- thread/resume: up to 25.791 seconds
I inspected the files only with fixed-size streaming samples, never by loading them fully:
- All three began embedding data:image/png;base64 near 3.5 MiB into the rollout.
- Random 1 MiB samples across most regions contained no line breaks and were effectively 100% Base64-compatible bytes.
- The three rollouts shared the same early image tool-call ID and PNG prefix, showing copied/forked ancestry.
- Forking therefore physically duplicated an already image-heavy history.
This strongly matches the inline-image amplification in #34863 and #28316. Loading several fork-related copies concurrently also appears to trigger the renderer history-retention/refetch failure described in #34890.
Reproduction pattern
- Use Codex Desktop with several concurrent long-running threads.
- Use browser/image tooling repeatedly so histories contain full-resolution inline PNG tool outputs.
- Allow repeated context compaction.
- Fork one or more of the image-heavy conversations.
- Keep the forked/original threads active or resumable in the desktop app.
- Observe codex.exe app-server repeatedly processing multi-GB rollout histories.
- The primary renderer grows toward roughly 4 GiB and creates a Crashpad ptype=renderer report.
- Electron automatically replaces the renderer.
- Under app-server load, persisted-state sync times out and the replacement renderer remains on the loading screen while background tasks continue.
Expected behavior
- Historical images should be externalized, deduplicated, or replaced with compact references after they are consumed.
- Forks should not physically duplicate multi-GB Base64 history.
- Renderer state for inactive/background threads should be bounded and loaded lazily.
- Renderer recovery should not immediately refetch every full thread history.
- If renderer recovery fails, the app should expose a safe UI-only retry that preserves the running app-server and active turns.
- The app should warn before a rollout becomes large enough to threaten process stability.
User impact and frustration
This is not just a performance nuisance. The app leaves background agents running but gives the user no supported way to recover only the UI. Once the window gets stuck on the loading screen, the user is forced to choose between an unusable app and killing the entire process tree in Task Manager, interrupting every active workstream and potentially losing in-progress context.
A productivity tool should not silently let one conversation grow to several gigabytes, duplicate that history again when a branch is created, crash its renderer, and then offer only "restart the app" as recovery. There is no visible warning about thread size, retained image bytes, renderer memory, or the risk of forking an image-heavy thread. This has happened repeatedly on current builds and needs urgent attention, including a safe UI-only reload path.
Additional notes
Crashpad uploaded the dumps and left only sidecars locally, so I do not have a local exception stack. The repeated ptype=renderer reports, approximately 4 GiB dominant-renderer footprint, renderer PID replacement, healthy system commit headroom, and continued app-server activity make renderer OOM the high-confidence failure mode.
I can provide redacted monitor CSV rows and desktop-log excerpts. The original rollouts contain private project screenshots and cannot be uploaded publicly.
Activity
github-actions commentedon Aug 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Teemo-Kingdom commentedon Aug 8, 2026
Same behavior here on 26.803.41515 (Windows 11 build 26200). Renderer dies silently while
app-server keeps completing turns (verified via logs_2.sqlite), replacement renderer stuck
on the loading screen forever. Additional evidence incl. Windows RADAR_PRE_LEAK_64 events
for both ChatGPT.exe and codex.exe in #37584.
RoshanDev commentedon Aug 11, 2026
Confirming a closely matching Windows reproduction on the same current package.
Environment
OpenAI.Codex 26.803.5235.026200Live read-only evidence
The UI first became severely unresponsive and then turned into a full white screen, while the backend Goal continued making progress.
At the white-screen state:
ChatGPT.exeprocess remained alive and Windows still reportedResponding=true;This appears to be a pre-crash/stuck-renderer variant of the same failure: background work and the app-server remain live, but the renderer can consume far more than 4 GiB and become completely unusable before it is recycled.
No processes were killed or restarted because an active task was still running. Raw rollouts and desktop logs are not attached because they contain private project and conversation data.
A supported UI-only reload/recovery path that preserves the app-server and active turns would be valuable, alongside bounded/lazy hydration of large active histories.
RoshanDev commentedon Aug 14, 2026
Follow-up: this reproduced again on a newer Windows package on 2026-08-14.
Environment
OpenAI.Codex 26.803.10989.026200New recurrence
The window became a full white screen again. Immediately before UI recovery, the dominant renderer had reached 7,110,209,536 bytes working set (about 6.62 GiB), while the separate shared app-server listener remained alive and the Goal database still reported the protected Goal as
active.The active rollout was 555,946,752 bytes before recovery. After restarting only the ChatGPT UI process tree, it had grown to 556,232,266 bytes, and the Goal remained
active, confirming that backend work continued across the unusable-UI interval and UI-only recovery.Recovery observations
Before the UI restart, a privacy-safe local backup was validated: 325,637 JSONL records parsed successfully, the file had a trailing newline, and both relevant SQLite snapshots returned
PRAGMA quick_check = ok.No raw rollout, prompts, screenshots, local paths, process IDs, or project data are attached. This recurrence suggests the renderer growth/loading-screen failure is still present in
26.803.10989.0, beyond the originally reported26.803.5235.0build.martinmclee commentedon Aug 20, 2026
Confirming a closely matching recurrent failure on Codex Desktop for Windows.
Observed behavior
I have not yet measured renderer memory or confirmed an OOM, so I cannot say that the root cause is identical to this issue, but the user-visible failure and recurrence pattern are very similar.
The biggest practical problem is that there is no obvious supported UI-only recovery path. When the renderer gets stuck on the logo while work may still be active, the user has to choose between leaving the app unusable or restarting the entire application and potentially interrupting an active Codex session.
A supported way to reload/recreate only the desktop UI while preserving the app-server and active turns would substantially reduce the impact of this bug.
I can provide the exact app version and sanitized logs/renderer memory observations on the next recurrence if maintainers need them.
sagirish commentedon Sep 17, 2026
This is still occurring. Surely this should be a fixable problem?!
LuckRef commentedon Sep 29, 2026
Reporting a related renderer-recovery pattern on the newer Windows app 26.924.22138, build 11645 / MSIX 26.924.2738.0: #49255
Six retained Crashpad sidecars identify the renderer (two September 28, four September 29). Across the inspected crashes, the desktop main process and app-server retained their original start times while the logo/UI reloaded. After the 09:22 local event, the log shows
React root render requested, thenNo promise for request IDandConversation state not found.A potentially relevant trigger in this case is upward history loading that continues without mouse/keyboard input in very long chats. The candidate session file is approximately 1.514 GB on disk. The report includes pre-crash history/layout counts and one crash that does not show the same preceding pattern.
I have not confirmed renderer OOM or an identical root cause. No processes were killed or history reset during diagnosis. Please correlate this newer-build evidence and advise on a supported UI recovery/mitigation that preserves ongoing work; inability to supervise active tasks is a serious practical impact.