›_ Codex Issues
Codex Issues / #31094

Codex desktop repeatedly crashes in CrBrowserMain with EXC_BREAKPOINT at temporal_rs_PlainDateTime_hour on macOS 26.6

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

I am reporting a serious recurring Codex desktop crash that has now happened at least 8 times across 2 Codex desktop builds. This is disrupting real business work. I am building a company and trying to do serious, production-oriented work with Codex; this instability is costing me time, money, and focus. I am very disappointed and need this treated as a real reliability issue, not a one-off local glitch.

Impact

  • Codex desktop has repeatedly crashed while I am actively trying to work.
  • The crashes keep interrupting business-critical setup and development work.
  • I have spent substantial time troubleshooting, reinstalling, collecting logs, and resetting local state instead of building my company.
  • I am paying for tooling and depending on Codex for serious work, so repeated desktop crashes create a direct cost in time and productivity.
  • I need guidance on whether this is a known app/runtime bug, whether there is a safe workaround, and when a fix can be expected.

Environment

  • macOS: macOS 26.6 (25G5052e)
  • Hardware: MacBookPro18,1
  • Codex desktop builds affected:
  • 26.623.81905 (4598)
  • 26.623.101652 (4674)
  • Bundled CLI: codex-cli 0.142.5
  • Codex Framework: 149.0.7827.197

Repeated crash signature

Every captured report has the same signature:

  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: 0 CrBrowserMain, com.apple.main-thread
  • Top frame: temporal_rs_PlainDateTime_hour + 5760080
  • Termination: SIGNAL, Trace/BPT trap: 5

Crash reports captured

  • 2026-07-02 01:51:31 -0500, PID 99454, incident 9961F8AE-39EB-45B7-BE29-B3C11834F59D
  • 2026-07-02 01:55:52 -0500, PID 2281, incident BC5B3D3B-9038-46E8-A055-DE92C2727EE0
  • 2026-07-02 02:09:45 -0500, PID 8784, incident 0100A4DA-A44E-4156-A7B9-DD122FDEBCEE
  • 2026-07-02 02:25:27 -0500, PID 10975, incident 6549D57F-ADB1-4DC6-99F2-869A79AA31ED
  • 2026-07-04 02:16:39 -0500, PID 47823, incident FB2CE82D-9A9D-4689-A142-96C659DAA7A0
  • 2026-07-04 02:26:53 -0500, PID 50790, incident 23D553F5-5874-4AC7-9A18-EB94A05EBC57
  • 2026-07-04 02:33:11 -0500, PID 53661, incident C82A9A76-ABF6-447F-88B4-8DEB536BE7B3
  • 2026-07-04 02:40:50 -0500, PID 54411, incident E30B67FA-30A1-45B9-BEA1-29DA1154E9BF

Troubleshooting already attempted

The crash persisted after:

  • Clearing volatile Codex/Chromium caches.
  • Disabling browser@openai-bundled.
  • Attempting to force browser backend to Chrome.
  • Fully resetting the Codex Chromium profile at 2026-07-02 02:00:11 -0500.
  • Reinstalling/updating the app.
  • Updating from 26.623.81905 (4598) to 26.623.101652 (4674).
  • Disabling chrome@openai-bundled as an additional no-browser-surfaces workaround.
  • Cleaning orphaned helper processes left after crashes.

Relevant observed behavior

Desktop logs repeatedly show in-app-browser / browser-use lifecycle activity around the crash window, including messages like:

IAB_LIFECYCLE iab backend info request failed
No Codex browser route is available for browser session ...
browser_use_iab_backend_startup_started ... backend=iab ... release=26.623.101652
browser_use_iab_backend_startup_ready ... backend=iab ...

The local configuration has also been rewritten back to:

BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab"

even after manually setting:

BROWSER_USE_AVAILABLE_BACKENDS = "chrome"

Current local mitigation

I have now applied the strictest local workaround I can identify:

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

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

BROWSER_USE_AVAILABLE_BACKENDS = "chrome"

This is only a temporary mitigation. It disables useful browser features and does not explain why the desktop app continues to crash in CrBrowserMain.

Request

Please investigate this as a Codex desktop app/runtime reliability bug. I need:

  • Confirmation whether this crash signature is known.
  • A recommended workaround that does not require giving up major Codex features permanently.
  • A fix or clear ETA if this is already being addressed.
  • Guidance on whether additional logs should be submitted through a private channel.

I have prepared a local support bundle containing .ips crash reports, pasted crash reports, app logs, and the troubleshooting summary. I am avoiding posting raw logs publicly because they may contain private session context, but I can provide them through /feedback or another private support channel.

Possibly related public issues

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 16 days ago

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

  • #30824
  • #30928
  • #30553

Powered by Codex Action

edyedinson · 16 days ago

Update: the crash has happened again after filing this issue.

New recurrence:

  • 2026-07-04 04:36:35 -0500, PID 59200, incident 77DE354B-A2B8-4F17-BFCB-48E12BA96DB6
  • App version: 26.623.101652 (4674)
  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: 0 CrBrowserMain, com.apple.main-thread
  • Top frame: temporal_rs_PlainDateTime_hour + 5760080

This brings the observed total to at least 9 crashes with the same signature.

Important additional detail: this recurrence happened after both browser-related plugins had been disabled locally:

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

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

The config had also been manually set to:

BROWSER_USE_AVAILABLE_BACKENDS = "chrome"

but after the crash, it was again observed as:

BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab"

So the no-browser-surfaces workaround is not holding reliably, and the app continues to crash in the same CrBrowserMain path. I have added the new .ips, pasted crash report, and matching app logs to the local/private support bundle for submission through /feedback or another private support channel.

edyedinson · 16 days ago

Update: another recurrence happened shortly after the previous one.

New recurrence:

  • 2026-07-04 04:41:38 -0500, PID 66843, incident 64E440AC-3137-4B56-A235-91167AFEEA69
  • App version: 26.623.101652 (4674)
  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: 0 CrBrowserMain, com.apple.main-thread
  • Top frame: temporal_rs_PlainDateTime_hour + 5760080

This brings the observed total to at least 10 crashes with the same signature.

Additional detail from this recurrence:

  • browser@openai-bundled remained disabled.
  • chrome@openai-bundled remained disabled.
  • BROWSER_USE_AVAILABLE_BACKENDS had again been rewritten to chrome,iab after being manually reset to chrome.
  • The crash-session desktop log still shows browser-use activity, including browser-use-pip Received Browser Use PiP metadata backend=chrome ..., despite the browser-related plugins being disabled.

I have added the new .ips, pasted crash report, and matching desktop logs to the local/private support bundle. This strongly suggests the local mitigation is not sufficient and the app/runtime is still entering the same browser/main-thread crash path.

edyedinson · 16 days ago

Another recurrence just happened after the prior mitigation.

New crash:

  • Time: 2026-07-04 04:47:10 -0500
  • PID: 68360
  • Incident ID: 3E94F1CA-4B3B-4478-B8AC-654B1844B556
  • App/build: 26.623.101652 (4674)
  • macOS: 26.6 (25G5052e)
  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: 0 CrBrowserMain / com.apple.main-thread
  • Top frame: temporal_rs_PlainDateTime_hour + 5760080

This brings the count to at least 11 crashes with the same signature. Both browser@openai-bundled and chrome@openai-bundled were still disabled. The app had again rewritten the local backend setting from BROWSER_USE_AVAILABLE_BACKENDS = "chrome" back to "chrome,iab", so the local mitigation is not holding.

I added the new .ips, pasted report, crashed-session log, and restart-session log to the local/private support bundle. Raw logs are still being kept out of the public issue because they may contain private session context.

edyedinson · 16 days ago

I tested again after the prior mitigation and it is not fixed.

Three more .ips reports appeared under ~/Library/Logs/DiagnosticReports/Retired, all with the same signature:

  • 2026-07-04 04:52:39 -0500, PID 70152, incident 6E43A413-B278-465D-8219-C84FE8745C16
  • 2026-07-04 04:57:56 -0500, PID 74352, incident 197CF13A-5CB3-47D4-BBA3-9079977A9279
  • 2026-07-04 05:14:39 -0500, PID 75049, incident FAFC2321-1831-4F19-A904-74AC95418A6D

Each one is:

  • App/build: 26.623.101652 (4674)
  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: CrBrowserMain / com.apple.main-thread
  • Top frame: temporal_rs_PlainDateTime_hour + 5760080

This brings the count to at least 14 matching crashes across the two desktop builds. During the test, ~/.codex/config.toml had again been rewritten to BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab", despite both browser@openai-bundled and chrome@openai-bundled being disabled. Logs from the restarted sessions still show browser_use_iab_backend_startup_started ... backend=iab and No Codex browser route is available ... warnings.

I added these new .ips files and session logs to the local/private support bundle. The currently running Codex instance after the crashes is PID 75849.

edyedinson · 12 days ago

Another recurrence, now on the newer desktop build.

Latest crash from the attached report and matching local .ips:

  • Time: 2026-07-08 13:47:58 -0500
  • PID: 37386
  • Incident ID: B8F0ABE2-4E36-403C-A4E7-F8C1B10EAEB0
  • App/build: 26.623.141536 (4753)
  • CLI: codex-cli 0.142.5
  • macOS: 26.6 (25G5052e)
  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: 0 CrBrowserMain / com.apple.main-thread
  • Top frame: temporal_rs_PlainDateTime_hour + 5760080

I also re-parsed every Codex .ips currently on disk under ~/Library/Logs/DiagnosticReports and ~/Library/Logs/DiagnosticReports/Retired: all 24 reports match this exact same signature. The affected desktop builds now include:

  • 26.623.81905 (4598)
  • 26.623.101652 (4674)
  • 26.623.141536 (4753)

The local config had again reverted to BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab", while both browser@openai-bundled and chrome@openai-bundled remained disabled. The restarted session on PID 40043 still logs browser_use_iab_backend_startup_started ... backend=iab ... release=26.623.141536.

I refreshed the local/private support bundle with all 24 .ips files, the new pasted report, and the crashed/restarted desktop logs. Raw logs are still not posted publicly because they may contain private session context.