Repository navigation
ChatGPT desktop app (26.707.31428, build 5059) OOMs on every launch — reproduces with fresh install, recreated state, offline #32192
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.31428, Build 5059 (bundleID com.openai.codex, installed as /Applications/ChatGPT.app)
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 24.6.0 arm64 arm — MacBookPro18,2, Apple M1 Max, 32 GB RAM, macOS 15.7.7 (24G720)
What issue are you seeing?
The consolidated ChatGPT desktop app crashes 25–41 seconds after every launch. The main process heap grows to ~3.4 GB and V8 aborts. Tail of the launch console log (10:04 launch, crash at 10:05:23):
[6659:0x128014b0000] 41475 ms: Mark-Compact (reduce) 3382.4 (3428.5) -> 3382.4 (3428.0) MB, pooled: 0.0 MB, 19.18 / 0.00 ms (average mu = 0.137, current mu = 0.001) last resort; GC in old space requested
[6659:0x128014b0000] 41494 ms: Mark-Compact (reduce) 3382.4 (3428.0) -> 3382.4 (3427.5) MB, pooled: 0.0 MB, 18.93 / 0.00 ms (average mu = 0.134, current mu = 0.001) last resort; GC in old space requested
[6659:112521:0710/100523.505724:ERROR:owl/common/node_bindings.cc:106] OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
zsh: trace trap /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
Note the heap is pinned at 3382.4 MB across successive last-resort compactions — it reclaims nothing, so this is live, reachable memory, not GC pressure.
Crash report metadata (ChatGPT-2026-07-10-101408.ips, the most recent of 12):
app_version 26.707.31428
build_version 5059
bundleID com.openai.codex
procPath /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
osVersion macOS 15.7.7 (24G720)
procLaunch 2026-07-10 10:13:27
captureTime 2026-07-10 10:14:08 (~41s alive)
exception EXC_BREAKPOINT / SIGTRAP, codes 0x0000000000000001, 0x00000001170c041c
termination SIGNAL, code 5, "Trace/BPT trap: 5"
faultingThread 0 — CrBrowserMain (com.apple.main-thread)
Top frames of the faulting thread, all in Codex Framework:
v8::ToExternalPointerTag(unsigned short)
v8::internal::compiler::CompilationDependencies::DependOnNoDateTimeConfiguration
v8::TryCatch::TryCatch(v8::Isolate*)
v8::Context::SetAlignedPointerInEmbedderData(int, void*, unsigned short)
v8::String::NewFromTwoByte(v8::Isolate*, unsigned short const*, v8::NewStringType, int)
node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, ...)
node::Buffer::RegisterExternalReferences(node::ExternalReferenceRegistry*)
Symbolication is nearest-symbol against the shipped stripped framework, so the exact names should be read with caution — but the shape is consistent with the GC trace: the main process OOMs while encoding a native buffer into a V8 string during startup.
12 crash reports were written on 2026-07-10 between 09:31 and 10:14, one per launch attempt.
What steps can reproduce the bug?
- Install ChatGPT desktop app 26.707.31428 (build 5059) on macOS 15.7.7, Apple Silicon.
- Launch the app.
- The window appears and loads. 25–41 seconds later the main process OOMs and the app dies.
100% reproducible here: 12 of 12 launch attempts on 2026-07-10 crashed, each producing a crash report.
What is the expected behavior?
App launches and stays running.
Additional information
Ruled out through testing — the crash reproduces after:
- Complete fresh install — deleted the app bundle, re-downloaded from the official site.
- Cleared
~/.codexand all Application Support state, Preferences, Saved Application State, HTTPStorages. Note that the app recreates~/.codexon every launch, and macOS Keychain credentials were never cleared, so each launch starts already authenticated. The crash reproduces in this recreated-state condition. - Network fully disabled (Wi-Fi off) — same OOM, so this is not the primary-runtime download.
- All Claude Code data removed — the
external-agent-importdetect stage is the last logged operation before the OOM in two separate console captures, but the crash persists withclaudeCodeItemCount=0.
Local state at crash time
~/.codex/sqlite/ 72 KB — codex-dev.db only; no state_*.sqlite
~/.codex/state_5.sqlite 180 KB — threads table: 0 rows
~/.codex/config.toml 288 bytes — no [agents] / max_threads settings
Why this is not #29007
#29007 ("Unbounded duplicated thread metadata can crash Desktop startup reconciliation via better-sqlite3 .all()") is the nearest existing report — same V8 OOM, same EXC_BREAKPOINT/SIGTRAP on CrBrowserMain, same crash before the window is usable.
It is not the same bug:
- In Unbounded duplicated thread metadata can crash Desktop startup reconciliation via better-sqlite3 .all() #29007 the allocation source is
better_sqlite3.nodeStatement::JS_allmaterializing ~2.15 GB of oversizedthreadsmetadata. Here thethreadstable has zero rows and the whole DB is 180 KB. - The reconciliation source DB (
~/.codex/sqlite/state_5.sqlite) does not exist at all. - No better-sqlite3 frame appears on the faulting stack. The frames are
node::Buffer→node::StringBytes::Encode→v8::String::NewFromTwoByte.
So something else is allocating multi-GB into V8 during startup, with essentially no local state to read.
Also not #31844 (excessive memory from a user-set [agents] max_threads = 1000): no such setting is present here, and that report is runtime growth during use, not a deterministic startup OOM.
A separate defect found while diagnosing: the keymap is read once per command
The app appears to read and parse ~/.codex/keybindings.json once per command while building menus, rather than once per launch. Two independent captures of two different launches each show exactly 313 accesses — the same count, under different conditions:
- fs_usage capture (09:59 launch, file absent): 313
opencalls on~/.codex/keybindings.json, every one returningENOENT, all from theChatGPTprocess, spanning 09:59:45.739 → 09:59:47.280 (1.54 s). - Console log (10:04 launch, file present containing
{}): 313[codex-command-keymap] Failed to parse command keymapentries, each aZodErrorreadingInvalid input: expected array, received object(the schema expects an array; the file contained{}).
The identical count across an absent-file run and a present-but-invalid-file run indicates one read/parse per command, not a time-based retry loop.
This is not the cause of the OOM. The 10:04 launch had the file present and still died with an identical heap profile and stack. Reporting it because 313 redundant file reads and 313 discarded Zod parses per launch looks like a bug worth fixing on its own.
Attachments
chatgpt-crash-evidence.zip — crash report (.ips), the launch console log containing the GC trace and V8 OOM message, and the fs_usage capture.
Activity
jjglawnyc commentedon Jul 10, 2026
chatgpt-crash-evidence.zip
jjglawnyc commentedon Jul 13, 2026
Still reproduces on 26.707.62119 (build 5211) — updated today from 5059, same crash on every launch.
Differences in this build's crash report: the crashed thread is now a V8Worker hitting brk 0 rather than CrBrowserMain. However, the main thread at crash time shows the identical stack from my original report — node::fs::AfterInteger → node::StringBytes::Encode → v8::String::NewFromTwoByte — i.e., still inflating a file/buffer into a V8 string. Also notable: a Node worker thread named git is active at crash time, which wasn't visible in the 5059 reports.
New .ips attached.
ChatGPT-2026-07-13-170412.ips.zip
jjglawnyc commentedon Jul 13, 2026
This appears to be the same SIGTRAP family as #32676 (filed same day, build 5200, repeated CrBrowserMain EXC_BREAKPOINT crashes, local state ruled out). Mine is the deterministic launch-time variant — OOM during an fs-read → StringBytes::Encode → NewFromTwoByte path, reproducing across builds 5059 and 5211. Related older reports with the same signature: #30553, #27880.
jjglawnyc commentedon Jul 13, 2026
Workaround found — same build (5211), no update involved.
After the crash reproduced on 26.707.62119 (5211) in my primary macOS user account, I: (1) created a fresh macOS user account, (2) did a clean reinstall of the app (same build — verified CFBundleVersion 5211 before and after), (3) launched in the fresh user and signed into the same OpenAI account — no crash, (4) logged back into my primary macOS user — app now launches normally there too, with no changes to that account's state or Keychain.
Implication: the fatal startup path appears to be a one-time operation that fails in the presence of existing per-user local state, but once it completes anywhere on the machine (or completes a server-side migration for the account), subsequent launches skip it everywhere. May help localize the bug — and gives stuck users an unblock path in the meantime.
guldanjaMAX commentedon Jul 23, 2026
Still reproducing on 26.715.72359 (build 5718), macOS 26.5.2, MacBook Air M4, 24 GB RAM. 13 days after this was filed and it is still shipping broken. Same signature: heap climbs to ~3.56 GB in about 2 seconds, V8 aborts with
CALL_AND_RETRY_LAST Allocation failed, crashed-thread stack stillnode::fs::AfterInteger → node::StringBytes::Encode → v8::String::NewFromTwoByte. Heap pinned across successive last-resort Mark-Compacts, reclaiming nothing, so it is live reachable memory, matching the original report.Independent isolation on my machine, which narrows it further:
CODEX_HOMEcontaining onlyauth.json.~/Library/Caches/com.openai.codex+HTTPStorageswiped.Most useful new data point: the bundled
codexCLI (codex-cli 0.145.0-alpha.30) runs fine on the exact same account and local state —codex execcompletes a real model call,codex doctoris green. The Rust app-server also starts cleanly and servesthread/list, plugins, and MCP every time. So the fault is isolated to the Electron main-process startup path, not auth, not the codex engine, not account connectivity.Can confirm the fresh-macOS-user workaround from the comment above is the current unblock. Given the CLI works untouched, this really looks like a one-time Electron-side startup/reconciliation step that fails only in the presence of existing per-user state (or a not-yet-completed per-account migration), consistent with #29007.
navneet-livio commentedon Aug 1, 2026
Same crash class here, and I think I have the missing measurement for it. Filed separately as #36523, cross-linking because your symptom profile matches closely.
What I measured.
lsofpolled every 150 ms across a full startup, aggregated by directory:99% of startup file I/O is a different application's support directory.
external-agent-import(import history from Claude Code / Cursor) opens 4,463local_*.jsonsession-metadata files totalling 1.72 GB under~/Library/Application Support/Claude/local-agent-mode-sessions/on every launch, regardless of age, and parses them into the JS heap.Before/after, same measurement, archiving stale
local_*.jsonand keeping only the last 3 days (4,463 files → 45):Peak startup RSS 2,857 MB → 1,280 MB; five consecutive cold launches afterwards, zero OOMs. Independent control: renaming
local-agent-mode-sessionsout of the scan path dropped the import scan from 5,900 ms → 39 ms.Two caveats on how this maps to your report. Your trace shows
CALL_AND_RETRY_LASTwith Mark-Compact "last resort" and the heap pinned at 3382.4 MB — live, unreclaimable memory. Mine isScavenger: semi-space copyat ~3,489 MB. Same ceiling, different allocation path, so these may be two doors into the same room rather than literally one bug. Also, you reproduced with a fresh install and offline, which my explanation would not cover on its own — unless the scan still found a populated~/Library/Application Support/Claude/on your machine, since a reinstall doesn't clear it. Worth checking: does your machine have Claude Desktop installed, and how large is that directory?If it does, the same archive test should be quick to replicate.
Also relevant: #29007 describes the same structural pattern in a different path — bounded UI metadata mixed with unbounded content, eagerly materialized at startup via
.all(). Whatever the fix here, an aggregate byte cap on startup materialization would cover all three.Diagnostic note for anyone else instrumenting this:
--js-flags="--heap-snapshot-near-heap-limit=N"is rejected by these builds (Error: unrecognized flag) — it's a Node flag, not a V8 flag — and a bare--max-old-space-sizeargument is silently ignored.--inspect/--inspect-brkdo work and expose a usable CDP endpoint on the main process.zaneperry commentedon Aug 10, 2026
I’m affected by what appears to be the same launch-time failure on a newer ChatGPT desktop build.
Environment:
26.803.41515/ build6321com.openai.codex, installed at/Applications/ChatGPT.app151.0.7922.7626.5.2 (25F84)Mac16,1, 16 GB RAMObserved behavior:
EXC_BREAKPOINT (SIGTRAP), terminationTrace/BPT trap: 5, faulting threadCrBrowserMainon the main thread.--user-data-dirstill reaches a V8 OOM around ~3.9 GB with:OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory--disable-gpukeeps the process alive longer, but no GUI window is created, so it is not usable.Local logs reached normal startup stages including auth, main-window readiness,
browser_use_iab_backend_startup_ready, and avatar overlay startup shortly before the crash/no-window behavior. Happy to provide crash/log details through a private channel if useful.wl1224 commentedon Aug 27, 2026
Has the problem been resolved? I encountered the same problem.😮💨