[app][macOS][26.803.41515] Codex desktop crashes on startup — V8 JavaScript heap out of memory (data-independent, org-wide)

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.41515 (6321) — bundled Codex app-server 0.147.0-alpha.6.5, Codex runtime offered 26.805.11740

What subscription do you have?

ChatGPT Pro (also reproduced with a second account in the same organization)

What platform is your computer?

macOS, Apple Silicon (arm64)

What issue are you seeing?

Summary

The new unified ChatGPT/Codex desktop app for macOS crashes with a V8 "JavaScript heap out of memory" error ~5–20 s after launch/login, making it completely unusable. Reproducible on two different Macs and two different accounts on the same organization/domain. It started on Aug 9, 2026 with no client build change, which points to a server-side rollout / feature flag. The crash is independent of user data (see Ruled out below). ChatGPT Classic and Codex CLI both work fine; only the new unified desktop app crashes.

Crash signature

<--- Last few GCs --->
Mark-Compact (reduce) 3552.4 (3592.9) -> 3552.4 (3588.9) MB
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

EXC_BREAKPOINT (SIGTRAP) on CrBrowserMain; heap tops out ~3.55 GB. A higher-RAM Mac renders the session list then crashes ~20 s in; a lower-RAM Mac crashes before the UI renders (blank white window).

Ruled out (this is NOT local / user data)

• Moved ~/.codex/sessions (25 GB) and ~/.codex/archived_sessions (9.6 GB) out of the way -> still crashes.
• The app's own store ~/Library/Application Support/com.openai.codex is only ~20 MB.
• The Codex Cloud account is empty (no tasks, no archived tasks) -> nothing large to load.
• Launching with --js-flags="--max-old-space-size=8192" -> crashes EARLIER (unbounded allocation, not a bounded one-time spike).
• Re-auth, second account, second machine, launch from Terminal -> all still crash.
• Reproduces with an essentially empty account -> the crash is independent of user data.

Suspected cause

A memory leak in the startup/init path (unbounded growth), likely gated by a server-side flag rolled out around Aug 9. Startup logs show repeated thread/list, thread/read and thread resume, plus these warnings:

WARN [Statsig] Creating multiple Statsig clients with the same SDK key can lead to unexpected behavior.
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 destroyed listeners added to [WebContents].

This looks like repeated provider mount/unmount creating Statsig clients / listeners until the heap is exhausted.

Impact

The new desktop app is unusable org-wide since Aug 9, 2026; we are forced onto Codex CLI + ChatGPT Classic.

Related: #33582 (macOS app grows to tens of GB and freezes), #33483 (crash after migrating to the new ChatGPT app).

Requested: bound/stream startup loads; fix the repeated-mount / Statsig / EventEmitter listener leak; if a server-side flag rolled out around Aug 9 triggered this, roll it back for affected organizations; add a safe-start that does not auto-load history. Full desktop logs and macOS crash reports available on request.

What steps can reproduce the bug?

Repro (happens on every launch):

Launch the new unified ChatGPT/Codex desktop app (build 26.803.41515) on macOS Apple Silicon and sign in. The app starts loading the session/thread list and memory climbs rapidly; within ~5–20 s the process dies with a V8 "JavaScript heap out of memory" error (SIGTRAP on CrBrowserMain), heap ~3.55 GB.

Reproduces on two different Macs and two different accounts in the same organization, continuously since Aug 9, 2026. Also reproduces with an essentially empty Codex Cloud account (local ~/.codex/sessions moved away; the app's own store is only ~20 MB). ChatGPT Classic and Codex CLI 0.147.0 are unaffected. It crashes during startup before any prompt is sent, so no specific session id / token usage applies.

What is the expected behavior?

The app should open and load the session/thread list without exhausting the V8 heap or crashing — i.e. bounded / streamed startup loading, with oversized or numerous items lazy-loaded rather than fully read into memory on launch.

Additional information

No response

No repository files or tests are named. First reproduce the launch crash and inspect the startup logs around repeated thread/list, thread/read, thread resume, Statsig clients, and WebContents listeners. Done means the macOS app loads the session/thread list with bounded memory and no V8 heap crash.