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
~/.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:
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.
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):
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):Top frames of the faulting thread, all in
Codex Framework: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?
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:
~/.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.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
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, sameEXC_BREAKPOINT/SIGTRAPonCrBrowserMain, same crash before the window is usable.It is not the same bug:
better_sqlite3.nodeStatement::JS_allmaterializing ~2.15 GB of oversizedthreadsmetadata. Here thethreadstable has zero rows and the whole DB is 180 KB.~/.codex/sqlite/state_5.sqlite) does not exist at all.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.jsononce 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:opencalls on~/.codex/keybindings.json, every one returningENOENT, all from theChatGPTprocess, spanning 09:59:45.739 → 09:59:47.280 (1.54 s).{}): 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 thefs_usagecapture.