Repository navigation
[macOS][26.908.40834] Renderer V8 OOM in chunked-message-receiver.join() when switching between large threads #45144
Description
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
- Open the desktop app with several existing long local threads containing substantial tool output and images.
- Open thread A, switch to B, return to A, and then open C. Continue switching at intervals of a few seconds.
- Observe the UI returning to its startup/loading screen after the renderer crashes.
- 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:
- Thread navigation/loading slows from unbounded metadata and eager large-history hydration #21211 — large-history hydration and navigation performance.
- macOS Desktop 26.818: task switching becomes multi-second again shortly after restart #40690 — task-switch latency and memory growth on macOS.
- ChatGPT desktop app freezes when switching to a large image-heavy thread (ResizeObserver loop) #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.
Activity
github-actions commentedon Sep 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
edwardswhiskeyblues-alt commentedon Sep 15, 2026
Adding a Windows corroboration with the same renderer-crash / UI-recovery shape as this report. I am adding it here rather than opening another issue because it overlaps both this OOM investigation and the Windows evidence in #45323 and #43557.
Environment
26.908.4834.0152.0.7977.830.154.0-alpha.6.2Observed behavior and crash correlation
Three local tasks were active and streaming concurrently. Their rollout files measured approximately
4.34 GiB,0.67 GiB, and0.32 GiB; all local session files together measured about13.5 GiB.Crashpad retained four renderer sidecars at the following local times (UTC+03:00):
11:58:3003:07:3610:17:4710:20:22Each sidecar contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}The main desktop process and app-server had remained alive since September 12. Replacement renderers appeared at
10:17:47and10:20:24. In the UI, the conversation disappeared, the GPT loading/splash state appeared, and the conversation was then repopulated while the background task continued. This confirms renderer recovery rather than a full application restart.Memory observations
During read-only sampling:
7.51 GiBof private memory; the app-server used another approximately1.3 GiB.784 MiB, and committed memory reached approximately91%of the system commit limit.14,236pages input/sec and disk traffic between approximately58and102 MB/sduring the sample.3321.3 MiBto3670.2 MiBprivate memory in about nine seconds. A second grew from2894.9 MiBto2992.0 MiBover the same interval.391 MiB, and the system drive still had approximately39.6 GiBfree. No matching Windows resource-exhaustion or display-driver reset event was found.These measurements strongly support memory pressure and large-history hydration as the trigger, but the retained sidecars do not contain the minidump annotations or stack needed to prove that the immediate failure was the same
chunked-message-receiver.join()V8 OOM documented here.Pending update excluded as the initiating cause
Package
26.908.9136.0had been downloaded and staged at01:12on September 15 but was not the running build. The active processes still belonged to26.908.4834.0, and the first renderer crash above occurred before the newer package was staged. The pending update therefore cannot be the sole initiating cause of this incident.This Windows occurrence supports bounded/paginated history assembly, cancellation of obsolete history loads after navigation, and renderer memory reclamation while multiple large tasks are active. No private task identifiers, titles, message contents, local paths, screenshots, account details, dumps, or raw logs are included.