›_ Codex Issues
Codex Issues / #32192

ChatGPT desktop app (26.707.31428, build 5059) OOMs on every launch — reproduces with fresh install, recreated state, offline

Open 💬 8 comments Opened Jul 10, 2026 by jjglawnyc

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?

  1. Install ChatGPT desktop app 26.707.31428 (build 5059) on macOS 15.7.7, Apple Silicon.
  2. Launch the app.
  3. 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 ~/.codex and all Application Support state, Preferences, Saved Application State, HTTPStorages. Note that the app recreates ~/.codex on 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-import detect stage is the last logged operation before the OOM in two separate console captures, but the crash persists with claudeCodeItemCount=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 #29007 the allocation source is better_sqlite3.node Statement::JS_all materializing ~2.15 GB of oversized threads metadata. Here the threads table 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 open calls on ~/.codex/keybindings.json, every one returning ENOENT, all from the ChatGPT process, 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 keymap entries, each a ZodError reading Invalid 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.

View original on GitHub ↗

8 Comments

jjglawnyc · 1 month ago

chatgpt-crash-evidence.zip

jjglawnyc · 1 month ago

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 · 1 month ago

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 · 1 month ago

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 · 1 month ago

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 still node::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:

  • Reproduces with a fresh CODEX_HOME containing only auth.json.
  • Reproduces with a fresh Chromium profile and ~/Library/Caches/com.openai.codex + HTTPStorages wiped.
  • Reproduces with all network blocked via a dead proxy (crash slips from ~6s to ~22s but still OOMs at the same 3.56 GB), so it is not parsing of any fetched payload.
  • Reproduces with statsig disabled.
  • Only stable state is signed out, which sits at ~0.4 GB indefinitely. My JWT claims decode as normal sized.

Most useful new data point: the bundled codex CLI (codex-cli 0.145.0-alpha.30) runs fine on the exact same account and local state — codex exec completes a real model call, codex doctor is green. The Rust app-server also starts cleanly and serves thread/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 · 26 days ago

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. lsof polled every 150 ms across a full startup, aggregated by directory:

AGGREGATE OPENED UNDER $HOME DURING STARTUP: 1.72 GB (4,422 files)

  1732.4 MB  (4298 files)  ~/Library/Application Support/Claude   <-- 99%
    25.2 MB  ( 114 files)  ~/Library/Application Support/Codex
     2.8 MB  (   3 files)  ~/Library/HTTPStorages/com.openai.codex
     2.4 MB  (   3 files)  ~/Library/Caches/com.openai.codex

99% of startup file I/O is a different application's support directory. external-agent-import (import history from Claude Code / Cursor) opens 4,463 local_*.json session-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_*.json and keeping only the last 3 days (4,463 files → 45):

| t | RSS before | RSS after |
|---|---|---|
| 2 s | 1,875 MB | 523 MB |
| 6 s | 2,857 MB | 1,250 MB |
| 10 s | 1,548 MB | 663 MB |
| steady | ~450 MB | ~671 MB |

Peak startup RSS 2,857 MB → 1,280 MB; five consecutive cold launches afterwards, zero OOMs. Independent control: renaming local-agent-mode-sessions out 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_LAST with Mark-Compact "last resort" and the heap pinned at 3382.4 MB — live, unreclaimable memory. Mine is Scavenger: semi-space copy at ~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-size argument is silently ignored. --inspect / --inspect-brk do work and expose a usable CDP endpoint on the main process.

zaneperry · 18 days ago

I’m affected by what appears to be the same launch-time failure on a newer ChatGPT desktop build.

Environment:

  • ChatGPT desktop: 26.803.41515 / build 6321
  • Bundle ID: com.openai.codex, installed at /Applications/ChatGPT.app
  • Codex Framework / Chromium base: 151.0.7922.76
  • macOS: 26.5.2 (25F84)
  • Hardware: Apple Silicon MacBook Pro, Mac16,1, 16 GB RAM

Observed behavior:

  • Normal launch crashes shortly after startup.
  • Crash report shows EXC_BREAKPOINT (SIGTRAP), termination Trace/BPT trap: 5, faulting thread CrBrowserMain on the main thread.
  • Launching with a clean --user-data-dir still reaches a V8 OOM around ~3.9 GB with:

OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

  • Launching with --disable-gpu keeps the process alive longer, but no GUI window is created, so it is not usable.
  • A narrower GPU-disable launch produced a window briefly, then still crashed with the same V8 OOM shape.

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 · 1 day ago

Has the problem been resolved? I encountered the same problem.😮‍💨