Repeated macOS Codex Desktop 26.609 crashes: CrBrowserMain EXC_BREAKPOINT, Renderer SIGABRT, stale app-server helpers

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

• #27349
• #27599
• #26869
• #26293

Powered by Codex Action

Thanks for the duplicate detection. I reviewed the suggested issues.

This may overlap with #27349, #27599, #26869, and #26293, but I am keeping this open for now because this report combines several symptoms in one macOS 26.609 case:

• repeated CrBrowserMain EXC_BREAKPOINT / SIGTRAP crashes
• matching Renderer SIGABRT crashes
• VM / memory pressure symptoms
• stale orphaned codex app-server
• long-lived xcodebuildmcp / node_repl / SkyComputerUseClient helper children after crash/restart

Happy to close or consolidate if maintainers prefer tracking this under one of the existing issues.

Same, happened three times today after the latest update, it's impossible to work.

I’m seeing the same crash family on a newer Codex Desktop build.

Environment:

• Codex Desktop: 26.609.41114 (CFBundleVersion 3888)
• Bundle ID: com.openai.codex
• macOS: 27.0 (26A5353q)
• Hardware: Mac15,12, Apple Silicon, 24 GB RAM
• Crash time: 2026-06-14 18:35:35 +0100

Crash summary:

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5
Triggered by Thread: 0 CrBrowserMain
Queue: com.apple.main-thread

Top triggered frames match the signature in this issue:

rust_png$cxxbridge1$194$Reader$has_trns_chunk
node::inspector::NodeInspectorClient::startRepeatingTimer(...)
temporal_rs_PlainDateTime_second
cppgc::internal::EnsureGCInfoIndexTrait::EnsureGCInfoIndex(...)
v8::Integer::New(...)
v8::internal::ThreadIsolation::LookupJitPageLocked(...)

Kernel triage also showed repeated VM/page fault symptoms:

VM - Fault was interrupted
VM - Waiting on busy page was interrupted

This happened while Codex Desktop had been running for several hours. I don’t have a deterministic repro, but this appears to confirm the CrBrowserMain / EXC_BREAKPOINT / rust_png...has_trns_chunk crash still occurs on 26.609.41114.

Adding a sanitized follow-up data point from another affected machine. My earlier the same comment was not useful enough; here is the actual diagnostic summary.

Environment:

• Codex Desktop versions seen in local crash reports:
• 26.608.12217 / build 3722
• 26.609.30741 / build 3808
• 26.609.41114 / build 3888
• Codex Framework / Chromium: 149.0.7827.54
• macOS: 26.5 (25F71)
• Hardware model: Mac17,6
• Architecture: Apple Silicon / ARM64

Crash pattern:

I have 9 main-process Codex crash reports from 2026-06-11 through 2026-06-16. All 9 have the same main-process signature:

Process: Codex
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: Trace/BPT trap: 5
Faulting thread: 0 / CrBrowserMain
Top frame: rust_png$cxxbridge1$194$Reader$has_trns_chunk
Nearby frames include:
  node::inspector::NodeInspectorClient::startRepeatingTimer(...)
  temporal_rs_PlainDateTime_second
  cppgc::internal::EnsureGCInfoIndexTrait::EnsureGCInfoIndex(...)
  v8::Integer::New(...)
  v8::internal::ThreadIsolation::LookupJitPageLocked(...)
  rust_bmp$cxxbridge1$194$Reader$metadata_loaded

Each main-process crash has a paired Codex (Renderer) .ips report at roughly the same timestamp with:

Process: Codex (Renderer)
Exception: EXC_CRASH / SIGABRT
Termination: Abort trap: 6
Top frames:
  __pthread_kill
  pthread_kill
  abort
  abort_report_np
  main

The local Codex app logs point strongly toward the in-app Browser / Browser Use path. For each crashed main-process PID, the final 500 lines of the matching codex-desktop-...-PID-t0...log contain about 488-500 lines matching browser/IAB/CDP lifecycle activity, including:

browser-use-iab-api
browser-session-registry
IAB_LIFECYCLE
executeCdp:Input.dispatchMouseEvent
executeCdp:Runtime.evaluate
getTabs

This makes the local evidence look more like a repeatable in-app Browser / Browser Use / CDP lifecycle crash than a random isolated memory-pressure event or a single corrupt crash report.

Local signing checks currently pass:

spctl --assess --verbose=4 /Applications/Codex.app
# accepted
# source=Notarized Developer ID

codesign --verify --deep --strict --verbose=2 /Applications/Codex.app
# valid on disk
# satisfies its Designated Requirement

So in this case I would not classify the primary crash as an invalid local app signature. I did observe a transient spctl failure with Too many open files while stale Codex helper processes were present, but a later check succeeded.

Other local observations:

• After crashes/restarts, multiple launchd-adopted Codex helper processes can remain from older app lifetimes, including old browser_crashpad_handler pairs and an orphaned codex app-server whose elapsed time does not match the current main app.
• Crashpad pending storage is not the primary symptom on this machine; it was only about 27 MB / 52 files when checked.
• Avoiding the Codex in-app Browser / Browser Use path appears to reduce exposure. Using external Chrome or Playwright is currently the practical workaround.

I can provide sanitized excerpts from the .ips files or full private crash reports if maintainers need them.

Adding a matching data point from another affected Mac.\n\nEnvironment:\n- Codex desktop surface in ChatGPT.app 26.727.51351, build 6119\n- Bundled Codex CLI 0.146.0-alpha.9.2\n- macOS 26.1 build 25B78\n- Apple Silicon\n- Crash time: 2026-08-03 04:56:46 NZST\n\nCrash signature:\n- EXC_BREAKPOINT / SIGTRAP\n- Termination: Trace/BPT trap: 5\n- Faulting main thread: CrBrowserMain\n- Stack includes the rust_png reader and Node/V8 bridge frames\n- This was not an operating-system reboot or an out-of-memory kill\n\nThe crash occurred during a long-running, image-heavy Codex orchestration task with several agents. The app relaunched, but the old task remained active through an orphaned pre-crash app-server. In that surviving task, every desktop task/thread tool then returned "No handler registered", including a read-only terminal call. That post-crash failure matches #28080.\n\nDiagnostics from codex doctor:\n- 178 active rollout files using about 12.16 GB\n- the affected active rollout was about 386 MB and still growing\n- state-store parity reported 585 stale rows\n- the current installation otherwise passed consistency checks\n\nExpected recovery: after a desktop crash, Codex should either reconnect the surviving task to the new desktop handlers or terminate the orphaned task host cleanly. It should not leave a task running without its desktop task tools.\n\nI have the local .ips crash report and can provide a sanitized copy if maintainers need it.