›_ Codex Issues
Codex Issues / #27349

Codex Desktop crashes when Browser opens in one thread while other non-Browser threads are active

Open 💬 7 comments Opened Jun 10, 2026 by donDinDonDev

Codex Desktop crashes immediately when the in-app Browser is opened in one thread while several other Codex threads/projects are already active.

Important detail: this was not a case of multiple Browser sessions. The other active threads were normal Codex threads and did not have Browser open.

Steps to reproduce

  1. Open Codex Desktop.
  2. Work in several threads/projects in parallel.
  3. Keep those existing threads active without using Browser in them.
  4. Start work in another thread/project.
  5. Let Codex open the in-app Browser in that thread.
  6. Codex Desktop crashes immediately.

Expected behavior

The Browser should open in the current thread, or fail gracefully without crashing the whole app.

Actual behavior

The whole Codex Desktop app crashed.

Environment

  • Codex Desktop: 26.608.12217
  • Codex Desktop build: 3722
  • Bundle ID: com.openai.codex
  • Bundled codex-cli: 0.138.0-alpha.7
  • Chromium framework: 149.0.7827.54
  • Bundled Node: v24.14.0
  • macOS: 26.5.1 (25F80)
  • Architecture: arm64
  • SIP: enabled

Crash / diagnostics summary

Feedback ID from the Codex crash dialog:

019eb08d-67f4-7a90-9fea-7c3dad8053b5

macOS crash reports were generated for both the main app process and the renderer process at the time of the crash.

Main Codex app crash summary:

Process: Codex
App version: 26.608.12217
Build: 3722
Exception: EXC_BREAKPOINT / SIGTRAP
Faulting thread: CrBrowserMain

Renderer crash summary:

Process: Codex (Renderer)
Renderer version: 149.0.7827.54
Exception: EXC_CRASH / SIGABRT

There was also a macOS diagnostic report shortly after the crash showing high disk writes by the Codex helper process:

Event: disk writes
Writes: about 8589.94 MB over 1232 seconds

After restarting, I observed multiple Codex-related helper processes, including several node_repl, codex app-server --listen stdio://, npm exec @playwright/mcp@latest, and playwright-mcp processes.

I am intentionally not pasting full crash reports here because they may contain local paths and device-specific identifiers, but I can provide sanitized excerpts if needed.

View original on GitHub ↗

7 Comments

SylvainWinning · 1 month ago

One detail that may be useful for narrowing this down: the post-crash process list suggests this may involve lifecycle cleanup across Browser/app-server/tooling processes, not just the Browser tab itself.

If this can be reproduced again, two extra diagnostics could make the crash more actionable:

  1. Whether the crash still happens after quitting Codex and confirming there are no remaining codex app-server, node_repl, playwright-mcp, or Chromium helper processes.
  2. Whether the macOS crash report has any frame names around browser-window creation, app-server WebSocket handling, or Chromium profile/session initialization immediately above the CrBrowserMain trap.

That would help distinguish “opening Browser while other threads exist” from “opening Browser while stale helper/browser state from previous threads is still alive”.

donDinDonDev · 1 month ago

Thanks, that distinction makes sense.

Based on the data I have right now:

  1. I have not yet reproduced it after a fully clean quit with all remaining codex app-server, node_repl, playwright-mcp, and Chromium helper processes confirmed gone. So I cannot say yet whether this reproduces from a clean state or only with stale helper/tooling state still alive.
  1. In the crash report excerpt I inspected, the main app crash is EXC_BREAKPOINT / SIGTRAP on the CrBrowserMain thread. The nearby visible frames are mostly Chromium/V8/Node/native-symbol frames; I did not see clearly named frames for browser-window creation, app-server WebSocket handling, or Chromium profile/session initialization in the visible portion above the trap.

The renderer report shows Codex (Renderer) starting immediately before the crash and aborting with EXC_CRASH / SIGABRT.

I avoided pasting full crash reports because they include local paths and device-specific identifiers, but I can try to reproduce from a clean process state and share sanitized excerpts if that would help.

donDinDonDev · 1 month ago

I reproduced the crash again with the first, simpler check.

Test result:

  • Quit and relaunched Codex Desktop.
  • Opened only the original thread where the previous crash happened.
  • Did not set up the previous parallel-thread / goal-mode situation.
  • Asked Codex to open the in-app Browser.
  • The Browser UI started to appear, showing a black viewport area before page content loaded. The viewport looked like a small mobile-sized viewport, roughly 390 x 800.
  • Codex Desktop crashed immediately after that.

So the crash does not require the earlier parallel-thread / goal-mode setup to reproduce, at least for this thread. I did not manually verify the helper process list immediately before this retry, but this was after quitting/relaunching Codex and using only the original thread.

Fresh macOS crash reports were generated at the time of this repro. They show the same overall pattern as before:

Main Codex app:

Process: Codex
App version: 26.608.12217
Build: 3722
Exception: EXC_BREAKPOINT / SIGTRAP
Faulting thread: CrBrowserMain

Renderer:

Process: Codex (Renderer)
Renderer version: 149.0.7827.54
Exception: EXC_CRASH / SIGABRT

The visible stack frames around the main crash again look like Chromium/V8/Node/native frames rather than clearly named browser-window/WebSocket/profile-init frames.

donDinDonDev · 1 month ago

One more context detail about the repro target, without local paths or specific local ports:

The in-app Browser was being opened against a local Vite/React frontend, with a local backend available behind the frontend dev-server proxy. This same local frontend/backend workflow had worked for me before in Codex.

In the failing case, the Browser does not appear to get as far as rendering the page content. The Browser UI starts, shows a black mobile-sized viewport, and then Codex Desktop crashes.

donDinDonDev · 1 month ago

Additional local diagnostics that may be relevant:

I inspected macOS unified logs and code-signing status around the reproduced crash. The local Codex.app installation appears to have a signing / entitlements problem.

codesign --verify reports:

/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: arm64

Checking entitlements for the main app and the Chromium/Electron helper apps (Codex (Renderer), Codex (GPU), Codex (Service), Codex (Alerts)) reports:

warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.

In the macOS unified log immediately before the renderer abort, I see repeated sandbox denials like:

denied lookup: name = com.openai.codex.MachPortRendezvousServer.1
requestor = Codex (Renderer)
error = 159: Sandbox restriction

Then ReportCrash logs:

ASI found [Codex (Renderer)] 'SeatbeltExec: buffer length read failed'
Forcing thread index 0 (SIGABRT)

This pattern appears in both reproduced crashes I checked. That seems consistent with the renderer failing during startup because required entitlements/Mach lookup permissions are not available, before the target page content renders.

donDinDonDev · 1 month ago

Update after reinstalling Codex Desktop:

The user reinstalled Codex Desktop, but the newly installed app still fails local code-signing validation.

Environment/build after reinstall:

  • Codex Desktop: 26.608.12217 / build 3722
  • Bundled CLI: codex-cli 0.138.0-alpha.7

Post-reinstall checks:

$ codesign --verify --verbose=4 /Applications/Codex.app
/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: arm64
$ codesign -d --entitlements :- /Applications/Codex.app
warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.
$ spctl -a -vv /Applications/Codex.app
/Applications/Codex.app: internal error in Code Signing subsystem

codesign -dv --verbose=4 also shows:

Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=2DC432GLL2
Notarization Ticket=stapled

This suggests the Browser/IAB crash may still be affected by the app's local code-signing/entitlements state even after a normal reinstall.

donDinDonDev · 1 month ago

Update after applying the latest Codex Desktop update:

The app updated successfully, but the local code-signing/entitlements problem still reproduces on the new build.

Version after update:

  • Codex Desktop: 26.609.30741 / build 3808
  • Bundled CLI: codex-cli 0.140.0-alpha.2
  • Chromium framework: still 149.0.7827.54

Checks after update:

$ codesign --verify --verbose=4 /Applications/Codex.app
/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: arm64
$ codesign -d --entitlements :- /Applications/Codex.app
warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.
$ spctl -a -vv /Applications/Codex.app
/Applications/Codex.app: internal error in Code Signing subsystem

codesign -dv --verbose=4 still shows:

Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=2DC432GLL2
Notarization Ticket=stapled

So the update changed the app/CLI build but did not resolve the invalid signature/entitlements state locally.