›_ Codex Issues
Codex Issues / #32676

Codex Desktop repeatedly crashes on macOS: CrBrowserMain EXC_BREAKPOINT/SIGTRAP in V8 code cache path

Open 💬 6 comments Opened Jul 13, 2026 by haloshin
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

Codex Desktop / ChatGPT macOS app repeatedly crashes while using Codex. The macOS crash reporter shows the same native crash signature each time:

  • EXC_BREAKPOINT / SIGTRAP
  • Trace/BPT trap: 5
  • faulting thread: CrBrowserMain
  • top frames repeatedly include:
  • ares_llist_replace_destructor
  • v8::ScriptCompiler::ConsumeCodeCacheTask::ConsumeCodeCacheTask(...)
  • v8::ScriptCompiler::CreateCodeCache(...) in later reports
  • v8impl::Reference::InvokeFinalizerFromGC()

This looks related to, but not exactly identical to, existing reports:

Frequency

Very frequent. There are 11 ChatGPT-2026-07-13*.ips crash reports on the machine today.

Recent crash reports:

ChatGPT-2026-07-13-101501.ips
ChatGPT-2026-07-13-101659.ips
ChatGPT-2026-07-13-102517.ips

The latest three all have the same pattern:

app_version: 26.707.61608
build: 5200
exception: EXC_BREAKPOINT / SIGTRAP
termination: Trace/BPT trap: 5
thread: CrBrowserMain

Environment

macOS: 26.5.1 (25F80)
machine: Apple Silicon, Mac16,8
ChatGPT/Codex app version from crash reports: 26.707.61608, build 5200
Codex CLI bundled in ChatGPT.app: codex-cli 0.144.0-alpha.4
Codex Framework shown in process args: 150.0.7871.115

Crash signature excerpt

From the latest reports, sanitized summary only:

exception: EXC_BREAKPOINT SIGTRAP
termination: Trace/BPT trap: 5
faulting thread: CrBrowserMain
frames:
ares_llist_replace_destructor
ares_llist_replace_destructor
ares_llist_replace_destructor
ares_llist_replace_destructor
ares_llist_replace_destructor
v8::ScriptCompiler::ConsumeCodeCacheTask::ConsumeCodeCacheTask(...)
v8::ScriptCompiler::ConsumeCodeCacheTask::ConsumeCodeCacheTask(...)
v8::ScriptCompiler::CreateCodeCache(v8::Local<v8::UnboundScript>)

Diagnostics already checked

Local Codex auth and SQLite state do not appear to be the cause:

auth mode: chatgpt
state_5.sqlite: integrity_check ok
logs_2.sqlite: integrity_check ok
goals_1.sqlite: integrity_check ok
memories_1.sqlite: integrity_check ok

No obvious auth/network patterns were present in local Codex logs:

hadToken=false: 0
Unauthorized: 0
websocket: 0
stream disconnected: 0
cannot access local database: 0
SQLite errors: 0

Mitigations attempted

  1. Moved Electron/Chromium cache-like directories out of ~/Library/Application Support/Codex:
  • Cache
  • Code Cache
  • GPUCache
  • GPUPersistentCache
  • GrShaderCache
  • ShaderCache
  • DawnGraphiteCache
  • DawnWebGPUCache
  • GraphiteDawnCache
  • component_crx_cache
  • extensions_crx_cache
  • several optimization/safety/component cache folders
  1. Disabled bundled browser/chrome plugins in ~/.codex/config.toml:
[plugins."chrome@openai-bundled"]
enabled = false

[plugins."browser@openai-bundled"]
enabled = false

The crashes continued after the first cache cleanup. The plugin-disable mitigation is currently being tested, but the user requested this issue because the crash frequency is high.

Expected behavior

Codex Desktop should not crash the entire ChatGPT/Codex macOS app during normal Codex use.

Actual behavior

The app exits and macOS shows "ChatGPT quit unexpectedly." Reopening the app works temporarily, but the same crash recurs.

Privacy note

I am not attaching the full .ips files publicly because they may contain local paths and machine-specific details. I can provide additional sanitized excerpts if helpful.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32399

Powered by Codex Action

miguelartazos · 1 month ago

Confirming the same signature on my machine — happy to add this as another data point.

Environment

macOS: 26.5.1 (25F80), Apple Silicon (Mac17,9)
App version: 26.715.31925 (build 5551)
Codex Framework: 150.0.7871.124
bundleID: com.openai.codex

Frequency: 10 crash reports in one day — 1 after ~15h of uptime overnight, then 9 more in a tight crash-loop within ~50 minutes this morning while just trying to relaunch the app. Reproduction rate on relaunch: effectively 100% once it started.

Signature (identical exception/offsets across all 10 reports):

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Termination:     Trace/BPT trap: 5
Faulting thread: 0 (CrBrowserMain)

Top frames (symbols are nearest-export guesses in a stripped binary, but consistent across every single crash):

0: ares_llist_replace_destructor                                    [+119273364]
1: v8::ToExternalPointerTag(unsigned short)                         [+80477292]
2: v8::ToExternalPointerTag(unsigned short)                         [+80477176]
3: v8::ExternalMemoryAccounter::Update(v8::Isolate*, long long)      [+25409088]
4: v8_simulator_probe_memory_continuation                            [+83856]
5: node::LibuvStreamWrap::HasDoTryWrite() const                      [+1946768]
6: v8::ValueSerializer::WriteValue(...)                              [+22496744]
7: v8::ValueSerializer::WriteValue(...)                              [+22492968]
8: v8::ValueSerializer::WriteValue(...)                              [+22498740]
9: v8::ValueSerializer::WriteValue(...)                              [+22499976]
10: v8::ValueSerializer::WriteValue(...)                             [+22498740]
11: v8::ValueSerializer::WriteValue(...)                             [+22499976]
12: v8::ValueSerializer::WriteValue(...)                             [+22492488]
13-37: ares_llist_replace_destructor (repeated, misattributed)

Note the ValueSerializer::WriteValue frames repeating in a tight A→B→A→B cycle (offsets 22496744/22492968/22498740/22499976 alternating) — looks like a recursive/cyclic serialization of something during startup, which then hits a fatal V8 check.

What I ruled out (each tested with a clean relaunch afterward, same crash every time — identical offsets in all cases):

  • Stale/corrupt V8 code cache — deleted ~/Library/Application Support/Codex/Code Cache and the Partitions/codex-browser-app/Code Cache — no change, crashed even faster (10s vs ~40-50s) with a cold cache.
  • Corrupt local/session storage or window-restore state — deleted Local Storage, Session Storage (root, Default/, and codex-browser-app/ partitions) and browser-sidebar-page-states.json — no change.
  • Corrupted local install — fully quit, removed, and freshly reinstalled ChatGPT.app from https://openai.com/chatgpt/download/ (same version, 26.715.31925/5551, since that's current) — crashed identically again.

Given the crash reproduces identically across a fresh install with a completely empty profile, this doesn't look like it can be fixed client-side — seems to require a fix in this app build. Crash timing scales inversely with cache warmth (30-50s cold-cache-absent → cached, 10s fully cold), consistent with something in early-startup IPC/state serialization rather than anything user-data-related.

Happy to share full sanitized .ips reports if a maintainer provides an upload route.

iangillespieunreal · 1 month ago

This error is happening to me as well. New mac, just downloaded the ChatGPT app. It will not load on my desktop. Please advise on a solution.

cavemanconsultinggroup-debug · 18 days ago

Same crash here — Apple Silicon M5, macOS 26.4.

Reproducing the exact CrBrowserMain EXC_BREAKPOINT / SIGTRAP in the V8 startup / code-cache path on a new M5 machine.

Environment:
App: ChatGPT / Codex Desktop, version 26.803.41515 (6321), identifier com.openai.codex
OS: macOS 26.4 (25E246)
Hardware: Mac17,6 (Apple Silicon, M5-class)
Code type: ARM-64 (Native)

Crash summary (from the .ips):
Triggered by Thread 0: CrBrowserMain, dispatch queue com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5

Top of the crashing thread:
0 Codex Framework ares_llist_replace_destructor + 21608
1 Codex Framework ares_llist_replace_destructor + 21500
2 Codex Framework reading_mode$cxxbridge1$194$parse_distilled_html + 13231356
3 Codex Framework reading_mode$cxxbridge1$194$parse_distilled_html + 13231236
4 Codex Framework v8::Isolate::Enter() + 57412
5 Codex Framework v8_simulator_probe_memory_continuation + 2292
6 Codex Framework v8::String::NewFromUtf8(...) + 328
7 Codex Framework node::StringDecoder::DecodeData(...) + 1028
8 Codex Framework node::StringDecoder::DecodeData(...) + 564
9 Codex Framework node ... _register_external_reference_string_decoder(...) + 916

What triggered it: crashes began right after signing out of one Codex account and into a different one. The app now crashes on every launch, before any window appears.

What I already tried (crash is identical after each): full uninstall + clean reinstall of the current build from the official download page; reset the data folder (~/Library/Application Support/Codex moved aside, app recreated a fresh empty one) still crashes; removed the stale ~/Library/Caches/com.openai.codex cache from an older version, still crashes.

So this is not user-data / cache related on my end — it's the build failing at V8/Node startup. Happy to attach the full .ips if useful.

acnorris17 · 17 days ago

Adding a deterministic Voice-specific M5 reproduction to this crash family.

Environment

  • ChatGPT / Codex desktop: 26.803.61601 (build 6396)
  • Bundle: com.openai.codex
  • macOS: 26.5.2 (25F84)
  • Hardware: Mac17,2, Apple Silicon M5
  • Architecture: ARM64 native

Deterministic trigger

The application otherwise works normally. It crashes immediately in either of these cases:

  1. Open a new, empty chat and select Voice before sending a message.
  2. Open Settings and select Voice.

The second path confirms that starting audio capture is not required; merely loading the Voice interface terminates the entire app.

Repeated signature

The crashes consistently show:

Exception: EXC_BREAKPOINT (SIGTRAP)
Termination: Trace/BPT trap: 5
Thread: 0 CrBrowserMain, com.apple.main-thread

Leading frames are identical across the reports and match the M5 report already in this thread:

ares_llist_replace_destructor + 21608
ares_llist_replace_destructor + 21500
reading_mode$cxxbridge1$194$parse_distilled_html + 13231356
reading_mode$cxxbridge1$194$parse_distilled_html + 13231236
v8::Isolate::Enter() + 57412

The issue has been reproduced repeatedly, including immediately after a complete clean-state reset.

Troubleshooting already ruled out

  • Updated the application and restarted macOS.
  • Verified the installed app has a valid OpenAI/Apple code signature.
  • Reset microphone permission for com.openai.codex.
  • Selected the built-in MacBook Pro microphone.
  • Disconnected AirPods and quit Teams/Webex.
  • Backed up and removed the new app's Application Support data, cache, and preferences so the app recreated a fresh profile.
  • Retested from a new, empty chat after the clean reset; identical crash.
  • Retested by opening Settings > Voice; identical crash.

Voice works with the same account on an M1 Mac and iPhone. Normal non-Voice use on this M5 is unaffected.

I have a privacy-limited support package containing four .ips crash reports and a diagnostic summary. I am not attaching raw reports publicly because they may include machine/local runtime details. Please provide a private upload route if the full reports would help.

This appears to be a reproducible Voice-interface initialization path into the existing CrBrowserMain/V8 failure, not a microphone, permission, account, cache, or corrupted-install problem.

xyzracehorse · 13 days ago

Repeated Codex Desktop V8 SIGTRAP / brk 0 crash — 13 occurrences in ~49.5h on build 6396

Issue body

Codex Desktop is repeatedly crashing and interrupting active work. This is a follow-up to an August 12 local investigation, with seven new macOS DiagnosticReports collected on August 13–14.

Environment

  • Codex Desktop: 26.803.61601 (build 6396)
  • Bundle ID: com.openai.codex
  • Chromium base: 151.0.7922.76
  • macOS: 26.6.1 (25G76)

Frequency and impact

  • Six same-signature crashes occurred on August 12.
  • Five additional crashes occurred on August 13.
  • Two additional crashes occurred on August 14.
  • Total: 13 same-build occurrences between August 12 at 06:11:34 and August 14 at 07:43:15, about 49.5 hours.
  • The app crashed again only 2 minutes 1 second after a prior crash on August 13, and 2 minutes 24 seconds after a prior crash on August 14, indicating rapid recurrence after relaunch.
  • The crashes repeatedly interrupt active work. This needs urgent stability attention.

Repeated crash signature

All seven new reports have:

  • EXC_BREAKPOINT / SIGTRAP
  • ESR: (Breakpoint) brk 0
  • Exact Codex Framework imageOffset: 71766936
  • The same first four frames:
  1. ares_llist_replace_destructor
  2. ares_llist_replace_destructor
  3. reading_mode$cxxbridge1$194$parse_distilled_html
  4. reading_mode$cxxbridge1$194$parse_distilled_html
  • Faulting thread: CrBrowserMain in five reports and V8Worker in two reports
  • Downstream V8 garbage-collection and heap-allocation frames

The earlier investigation also found embedded OOM error in V8 and Allocation failed - JavaScript heap out of memory strings. The machine had ample physical memory at the time, supporting per-process V8 heap exhaustion rather than whole-system memory pressure.

This recurring signature is distinct from the separate August 11 EXC_BAD_ACCESS drag-and-drop renderer crash and should not be grouped with it.

Reproduction status

No single deterministic click sequence has been isolated. The failure occurs during ordinary Codex Desktop use and can recur within minutes after relaunch. Large active histories and heavy task switching appear correlated, but are not claimed as the root cause.

Expected behavior

The desktop app should remain stable during normal use and after relaunch.

Actual behavior

The Chromium/V8 process repeatedly terminates with the same breakpoint and stack signature, losing the active app session and disrupting work.

Attachments

The accompanying archive contains only these seven new macOS .ips reports:

  • ChatGPT-2026-08-13-085021.ips
  • ChatGPT-2026-08-13-091949.ips
  • ChatGPT-2026-08-13-092150.ips
  • ChatGPT-2026-08-13-104519.ips
  • ChatGPT-2026-08-13-200310.ips
  • ChatGPT-2026-08-14-074051.ips
  • ChatGPT-2026-08-14-074315.ips

Broad conversation histories, session transcripts, and unrelated application logs are not included.

Feedback-submission blocker observed on August 14

An additional Codex Desktop browser-permission defect prevented this evidence from being submitted through the official GitHub issue form:

  • github.com was added under Settings > Browser > Allowed sites.
  • No github.com entry was visible under Blocked sites.
  • Codex Desktop was fully quit and relaunched so the permission state would reload.
  • A fresh built-in browser instance still rejected https://github.com/openai/codex/issues/new/choose before the page loaded, reporting that a saved user permission setting blocks https://github.com.

Computer Use correctly refused to bypass the saved site policy. The mismatch between the visible Allowed-sites state and the enforced hidden Block state appears to be a second reproducible Codex Desktop bug. No GitHub issue URL or number was issued because the page never loaded.

codex-crash-evidence-2026-08-14.zip