Codex 26.609.41114 crashes and triggers “Codex Computer Use is damaged and can’t be opened” on macOS 26.5.1

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

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.609.41114
Build 3888
Released Jun 12, 2026

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS Tahoe 26.5.1 (25F80)
Apple Silicon / ARM64
MacBook Pro 16-inch, Apple M5 Max, 128 GB memory
Hardware Model: Mac17,6

What issue are you seeing?

Codex quit unexpectedly while I was using the Codex desktop app. Around the same time, macOS also displayed a Gatekeeper-style warning for the Computer Use helper:

“Codex Computer Use” is damaged and can’t be opened. You should move it to the Trash. This file was downloaded on an unknown date.

This appears to be related to the Codex desktop app’s Computer Use / browser automation helper. The crash report shows that the main Codex app crashed, not just the helper.

Crash summary from macOS Problem Report:

  • Process: Codex
  • Path: /Applications/Codex.app/Contents/MacOS/Codex
  • Identifier: com.openai.codex
  • Version: 26.609.41114 (3888)
  • Code Type: ARM-64 (Native)
  • OS Version: macOS 26.5.1 (25F80)
  • Hardware Model: Mac17,6
  • Date/Time: 2026-06-15 00:44:09 -0700
  • 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
  • Faulting frame includes:
  • Codex Framework
  • rust_png$cxxbridge1$194$Reader$has_trns_chunk
  • later frames include rust_bmp$cxxbridge1$194$Reader$metadata_loaded
  • System Integrity Protection: enabled

What steps can reproduce the bug?

I do not yet have a fully deterministic minimal reproduction, but the issue happened during normal Codex desktop usage involving Computer Use / browser automation.

Observed sequence:

  1. Open Codex desktop app on macOS.
  2. Use Codex normally with Computer Use / browser automation available.
  3. Codex unexpectedly quits.
  4. macOS shows the crash report: “Codex quit unexpectedly.”
  5. macOS also shows a warning dialog saying:
  • “Codex Computer Use” is damaged and can’t be opened.
  • “You should move it to the Trash.”
  • “This file was downloaded on an unknown date.”

What is the expected behavior?

Codex should not crash.

The bundled or installed “Codex Computer Use” helper should remain valid, properly signed/notarized, and launchable by macOS. Computer Use should either work normally or fail gracefully with a recoverable error message inside Codex, not trigger a macOS “damaged app” dialog and crash the main Codex desktop app.

Additional information

This looks related to other recent Computer Use / macOS Gatekeeper reports, but this report is for a newer Codex desktop version:

  • Codex App: 26.609.41114 (3888)
  • macOS: 26.5.1 (25F80)
  • Exception: EXC_BREAKPOINT (SIGTRAP)
  • Triggered thread: CrBrowserMain
  • Machine: Apple Silicon MacBook Pro, M5 Max, 128 GB memory

I can provide the full macOS crash report if needed.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28184
  • #28250
  • #27880

Powered by Codex Action

huihaixiao-ctrl · 2 months ago

I hit what appears to be the same crash signature three times today on Codex Desktop 26.609.41114 (build 3888) on macOS 26.5.1 (25F80), Apple Silicon / ARM64.

Crash times, local timezone +0800:

2026-06-15 11:29:49 - Codex main process EXC_BREAKPOINT / SIGTRAP
2026-06-15 16:35:13 - Codex main process EXC_BREAKPOINT / SIGTRAP
2026-06-15 18:32:24 - Codex main process EXC_BREAKPOINT / SIGTRAP

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

Main-process incidents:

4008E420-463E-4556-BE87-7CD3069F3A1E
F7E89487-30ED-4FCF-9D7A-2E04267CAC50
06AD8EA1-C4A1-4C96-A9F6-C501B6B88B76

Common main-process signature across all three:

Exception: EXC_BREAKPOINT / SIGTRAP
Termination: Trace/BPT trap: 5
Faulting thread: CrBrowserMain
Top frame: rust_png$cxxbridge1$194$Reader$has_trns_chunk
Next frame: NodeInspectorClient::startRepeatingTimer(...)
Nearby frames include V8 / Node / cppgc and rust_bmp$cxxbridge1$194$Reader$metadata_loaded

The most recent crash happened immediately after an in-app Browser / Browser Use action started. Local app logs show a Browser js tool call around 18:32:24.544 +0800 navigating to http://127.0.0.1:4318, then the main process crash was captured at 18:32:24.8629 +0800. Around the same window there were shutdown/cancellation logs for MCP services, but those look like consequences of the crash/shutdown rather than the root cause.

I have the six macOS DiagnosticReports .ips files packaged locally and can provide them through a private support channel if useful. I am not attaching the full reports publicly because they may include local paths, device identifiers, timestamps, and process details.

linc77 · 2 months ago

解决了吗

huihaixiao-ctrl · 2 months ago

Update: I reproduced the same crash signature again after updating to Codex Desktop 26.609.71450 build 3965 on macOS 26.5.1 (25F80).

New crash time, local timezone +0800:

2026-06-16 21:13:15 - Codex main process EXC_BREAKPOINT / SIGTRAP

New incidents:

Main process: 8D27B994-FD0E-4E4A-AA08-9728C3C30506
Renderer: 06A4F31C-6AF1-42BA-B023-8C9DBBBC3A41

Main-process signature is unchanged:

Exception: EXC_BREAKPOINT / SIGTRAP
Termination: Trace/BPT trap: 5
Faulting thread: CrBrowserMain
Top frame: rust_png$cxxbridge1$194$Reader$has_trns_chunk
Nearby frames include V8 / Node / cppgc and rust_bmp$cxxbridge1$194$Reader$metadata_loaded

This time the desktop app log gives a tighter pre-crash sequence. Immediately before the crash it shows Browser Use lifecycle events:

13:13:15.280Z browser_viewport_set
13:13:15.289Z createTab
13:13:15.298Z created hidden Browser Use webview with about:blank
13:13:15.304Z requested browser sidebar webview attachment
13:13:15.316Z attached Browser Use guest webContents
21:13:15.5533 +0800 main-process crash captured

So the issue still reproduces on 26.609.71450 and appears tightly correlated with Browser Use creating/attaching the hidden webview. I have the two new macOS DiagnosticReports .ips files packaged locally and can provide them through a private support channel if needed.

huihaixiao-ctrl · 2 months ago

Another recurrence of the same crash family.

Private Codex /feedback for this investigation was previously submitted with feedback ID 019ecaea-34b5-7c22-9dc2-af77ac23b96e.

New crash:

  • Local time: 2026-06-17 00:03:55 CST (2026-06-16T16:03:55Z)
  • Codex: 26.609.71450 build 3965
  • macOS: 26.5.1 (25F80), device Mac17,2
  • Main incident: 27ADAC20-1184-4917-A548-EDE07CA02E1F
  • Renderer incident: FDC595A8-E5E2-4207-8C29-A8432C866751
  • Main exception: EXC_BREAKPOINT / SIGTRAP, termination SIGNAL 5
  • Fault thread: CrBrowserMain
  • Top frame: rust_png$cxxbridge1$194$Reader$has_trns_chunk
  • Renderer paired report: EXC_CRASH / SIGABRT, termination SIGNAL 6
  • Local Sentry queue remained empty (queue-v2.json length 0, session status ok, errors 0)

The app log ended immediately during Browser Use / IAB webview creation. Last relevant lifecycle events before termination:

  • 2026-06-16T16:03:55.154Z: browser-use-iab-api received executeUnhandledCommand:browser_viewport_set
  • 2026-06-16T16:03:55.155Z: browser-sidebar-manager opened a browser-use tab (appBrowserUseTabCount=1)
  • 2026-06-16T16:03:55.158Z: renderer created browser sidebar webview (hostKind=hidden-browser-use, initialUrl=about:blank)
  • 2026-06-16T16:03:55.159Z: browser-use-iab-api received createTab
  • 2026-06-16T16:03:55.159Z: waiting for browser sidebar webview attachment / browser-use open wait started

The log file had no later lines; the main crash report capture time was 2026-06-16T16:03:55.452Z, about 293 ms after the last IAB lifecycle log. Full .ips reports are available locally and can be attached through a private channel if needed.