Skip to content

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

Open

Description

@Mnagalah

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:

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

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Sep 13, 2026
  2. github-actions commented on Sep 13, 2026

    @github-actions
    Contributor
  3. edwardswhiskeyblues-alt commented on Sep 15, 2026

    @edwardswhiskeyblues-alt

    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

    • Windows 11 x64, build 26200
    • Installed and running Codex Desktop package: 26.908.4834.0
    • Embedded Chromium: 152.0.7977.83
    • Bundled app-server: 0.154.0-alpha.6.2

    Observed behavior and crash correlation

    Three local tasks were active and streaming concurrently. Their rollout files measured approximately 4.34 GiB, 0.67 GiB, and 0.32 GiB; all local session files together measured about 13.5 GiB.

    Crashpad retained four renderer sidecars at the following local times (UTC+03:00):

    • September 14, 11:58:30
    • September 15, 03:07:36
    • September 15, 10:17:47
    • September 15, 10:20:22

    Each 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:47 and 10: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:

    • The ChatGPT desktop process family had 18 processes using approximately 7.51 GiB of private memory; the app-server used another approximately 1.3 GiB.
    • Available physical memory temporarily fell to 784 MiB, and committed memory reached approximately 91% of the system commit limit.
    • Paging was active, with an observed average of roughly 14,236 pages input/sec and disk traffic between approximately 58 and 102 MB/s during the sample.
    • One replacement renderer grew from 3321.3 MiB to 3670.2 MiB private memory in about nine seconds. A second grew from 2894.9 MiB to 2992.0 MiB over the same interval.
    • ChatGPT GPU shared-memory use was approximately 391 MiB, and the system drive still had approximately 39.6 GiB free. 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.0 had been downloaded and staged at 01:12 on September 15 but was not the running build. The active processes still belonged to 26.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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancesessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions