[Windows 11][26.803.5235.0] Renderer OOM auto-reload leaves Codex stuck on loading screen while app-server tasks continue

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

1. Use Codex Desktop with several concurrent long-running threads.
2. Use browser/image tooling repeatedly so histories contain full-resolution inline PNG tool outputs.
3. Allow repeated context compaction.
4. Fork one or more of the image-heavy conversations.
5. Keep the forked/original threads active or resumable in the desktop app.
6. Observe codex.exe app-server repeatedly processing multi-GB rollout histories.
7. The primary renderer grows toward roughly 4 GiB and creates a Crashpad ptype=renderer report.
8. Electron automatically replaces the renderer.
9. 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.