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

Activity

1. Culaliya

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 12, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   browser

   computer-use

   performance

   on Jun 12, 2026
3. github-actions commented on Jun 12, 2026

   

   github-actionsBot

   on Jun 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop crashes when Browser opens in one thread while other non-Browser threads are active #27349
   • Codex Desktop repeatedly crashes with EXC_BREAKPOINT/SIGTRAP and VM fault symptoms when git/review worker scans large generated output #27599
   • Codex Desktop app-server leaks child processes and writes excessive logs after crash/restart #26869
   • SkyComputerUseClient processes spawned for turn-ended events remain alive as PPID=1 orphans #26293

   Powered by Codex Action
4. Culaliya commented on Jun 12, 2026

   

   Culaliya

   on Jun 12, 2026

   Author

   More actions

   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.
5. giorebil commented on Jun 12, 2026

   

   giorebil

   on Jun 12, 2026

   More actions

   Same, happened three times today after the latest update, it's impossible to work.
6. rmilkowski commented on Jun 14, 2026

   

   rmilkowski

   on Jun 14, 2026

   More actions

   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.
7. Tigranchick commented on Jun 15, 2026

   

   Tigranchick

   on Jun 15, 2026

   Last edited by Tigranchick

   More actions

   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.
8. nickjohngray commented on Aug 2, 2026

   

   nickjohngray

   on Aug 2, 2026

   More actions

   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.