[macOS][26.908.40834] Renderer V8 OOM in chunked-message-receiver.join() when switching between large threads

App version

26.908.40834 (build 8881), read from the installed app bundle.
Embedded framework version: 152.0.7977.83.

Subscription

ChatGPT Pro x20

Platform

macOS 26.6.2 (25G83), Apple Silicon, 24 GB unified memory (user-reported).
uname -mprs: Darwin 25.6.0 arm64 arm

Observed problem

Switching repeatedly between several large local threads causes the desktop renderer to crash and the main window to return to its startup/loading screen. The application then reloads the UI. Background task execution continues; the main application process and the Codex backend process remain alive.

This was reproduced during a local diagnostic session on September 13, 2026. A native renderer minidump captured at approximately 08:11:40 UTC+08:00 contains V8 OOM annotations identifying the immediate failure inside the host-to-renderer chunked message assembler.

Reproduction steps

1. Open the desktop app with several existing long local threads containing substantial tool output and images.
2. Open thread A, switch to B, return to A, and then open C. Continue switching at intervals of a few seconds.
3. Observe the UI returning to its startup/loading screen after the renderer crashes.
4. After recovery, observe that background tasks have continued.

The three involved local rollout files are approximately 640 MiB, 2958 MiB, and 331 MiB. These are complete persisted log sizes, not measurements of bytes loaded into the UI. All three records have history_mode=paginated.

This is reproducible with the existing private histories; a minimal synthetic reproduction has not yet been created. Private thread identifiers and contents are omitted.

Expected result

Switching among existing threads should keep the UI responsive and avoid renderer crashes. Historical data loading and message assembly should have bounded memory use, including when a user navigates away before loading completes. Full history should remain accessible without requiring deletion or replacement of existing threads.

Diagnostic evidence and related reports

Selected annotations extracted from the captured renderer minidump:

v8-oom-location: CALL_AND_RETRY_LAST
v8-oom-is-main-isolate: true
v8-oom-memory-allocator-size: 3174.56MB
v8-oom-memory-allocator-capacity: 4192.00MB
v8-oom-lo-space-size: 2577.16MB
v8-oom-old-space-size: 526.55MB

The last two last-resort GC attempts both retained approximately 3080.2 MB of live heap. Their log messages report allocation failure / GC in old space requested. The capacity field is not a measurement of immediately available free memory.

V8 OOM JavaScript stack:

join
consume in app://-/assets/chunked-message-receiver-f7dc99866884.js
receive in =
u in app://-/assets/get-trusted-message-for-view-eee599500f15.js
l in =
handleMessage in app://-/assets/message-bus-828b3d0e2c34.js
windowMessageListener in =
<none>
emit in node:electron/js2c/sandbox_bundle
onMessage in =
$

Read-only inspection of the matching installed script places this stack at the assembler's string-end handling, which calls this.stringChunks.join("").

Desktop logs also show history responses for a previously visited thread arriving after navigation to another thread. During this reproduction, a prior thread's thread/turns/list completed at 08:11:38.741 UTC+08:00, after navigation at 08:11:38.614; the renderer crashed at about 08:11:40. This is consistent with overlapping history loading/retention increasing memory pressure, but the exact triggering response and the object retaining paths have not been established.

Sentry classified the renderer exit as reason=crashed, exitCode=5. ResizeObserver loop completed with undelivered notifications errors were also present; the captured OOM stack specifically points to message-string assembly, so the layout warnings are not established as the direct cause.

Related reports reviewed:

• https://github.com/openai/codex/issues/21211 — large-history hydration and navigation performance.
• https://github.com/openai/codex/issues/40690 — task-switch latency and memory growth on macOS.
• https://github.com/openai/codex/issues/33782 — switching into a large image-heavy thread and layout-loop errors.

This report adds a captured renderer OOM stack in chunked-message-receiver and the automatic UI reload / continuing backend behavior. I cannot confirm whether it shares the same underlying defect as those reports; please consolidate if appropriate.

Raw session histories and the native minidump are retained locally and are not included in this public report. The excerpts above omit account identifiers, private project paths, thread titles, and conversation contents.

Start by inspecting the installed chunked-message-receiver script at the reported string-end join() path and review the captured renderer minidump annotations. Compare history responses that arrive after navigation with the related large-history and task-switch reports. Done means repeated switching through large existing threads no longer crashes or reloads the renderer, while full history remains accessible with bounded memory use.