›_ Codex Issues
Codex Issues / #32399

Codex Desktop crashes with EXC_BAD_ACCESS seconds after in-app Browser Use debugger attaches

Open 💬 8 comments Opened Jul 11, 2026 by gletushov
💡 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)?

26.707.41301 (build 5103)

What subscription do you have?

ChatGPT account (exact tier not included in this report)

What platform is your computer?

Darwin 25.3.0 arm64 arm

macOS 26.3 (25D125), Mac14,2, Apple M2, 16 GB RAM.

What issue are you seeing?

Codex Desktop repeatedly crashes when Browser Use opens an in-app browser tab during a Playwright/browser-automation task.

This is a native app crash, not a Playwright exception. macOS records:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000548
Triggered by Thread: 0 CrBrowserMain, com.apple.main-thread
Top frame: Codex Framework!v8impl::Reference::InvokeFinalizerFromGC()

Four crashes with the same signature occurred across July 10-11, 2026. In every case, the last Browser Use lifecycle event was registered debugger listener, followed by the native crash 1.1-2.5 seconds later:

2026-07-10T11:18:30.696Z registered debugger listener
2026-07-10 15:18:33.2202 +0400 crash (2.52 seconds later)

2026-07-10T13:59:54.939Z registered debugger listener
2026-07-10 17:59:56.9156 +0400 crash (1.98 seconds later)

2026-07-11T11:30:33.472Z registered debugger listener
2026-07-11 15:30:35.5471 +0400 crash (2.08 seconds later)

2026-07-11T11:31:49.061Z registered debugger listener
2026-07-11 15:31:50.1824 +0400 crash (1.12 seconds later)

The timestamps in the app log are UTC; the crash report timestamps are UTC+4.

After one restart, the app also repeatedly logged this before a new browser route was established:

No ChatGPT browser route is available for browser session [redacted]

What steps can reproduce the bug?

  1. Launch Codex Desktop on macOS Apple Silicon.
  2. Start or continue a task that asks Codex to use Playwright/Browser Use and open a website in the in-app browser.
  3. Codex creates and attaches the hidden Browser Use WebView.
  4. The app log reaches IAB_LIFECYCLE registered debugger listener.
  5. Codex exits with EXC_BAD_ACCESS / SIGSEGV within a few seconds.
  6. Relaunching Codex and retrying can reproduce the same crash immediately.

Observed reproduction rate for the captured incidents: 4/4.

What is the expected behavior?

The in-app browser should open and remain attached while Codex runs the browser automation. A failed or stale browser route should be recovered or reported as a normal error without crashing the Codex process.

Additional information

  • The crash occurs in the Codex Framework Chromium/V8 main thread, not in the separately bundled Node/Playwright process.
  • All four macOS .ips reports have the same exception, faulting queue, top frame, and framework.
  • The machine was not under an out-of-memory termination; the reports show an invalid-address access at 0x548.
  • Full .ips crash reports and targeted Codex logs are available if maintainers provide a private upload route. They are not attached publicly because raw app logs contain local paths and session metadata.
  • Current workaround: run Playwright as an external/headless terminal process and avoid opening the Codex in-app browser.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 9 days ago

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

  • #32334

Powered by Codex Action

JonReed · 7 days ago

I can reproduce this on Codex App 26.707.62119 (build 5211), macOS 26.5.1 (25F80).

The in-app Browser Use session crashes Codex when the hidden browser attaches or navigation begins. I reproduced it twice after restarting Codex and creating fresh browser sessions.

Crash reports show:

  • EXC_BAD_ACCESS / SIGSEGV
  • KERN_INVALID_ADDRESS at 0x548
  • Faulting thread: CrBrowserMain
  • V8 frame: v8impl::Reference::InvokeFinalizerFromGC()

The matching Codex logs also show:

  • “No ChatGPT browser route is available”
  • “mcp-app-sandbox.attach_unmatched”
  • “urlProtocol=invalid”

Crash times were 2026-07-13 10:30 and 11:38 Europe/London.

SeanIH · 7 days ago

Posted by Codex on behalf of the reporter.

We reproduced the same native crash signature on a newer Codex build.

Environment:

  • Codex app 26.707.62119 (build 5211)
  • macOS 26.5.2 (25F84), Apple Silicon

The in-app browser crashed Codex while opening an external Vercel preview. The in-app path crashed on two attempts; the available .ips report is from the retry after updating the app. Opening the same website through the Chrome Browser Use path succeeded.

The crash report matches this issue:

  • EXC_BAD_ACCESS (SIGSEGV)
  • KERN_INVALID_ADDRESS at 0x0000000000000548
  • Thread 0: CrBrowserMain, main thread
  • Top frame: Codex Framework v8impl::Reference::InvokeFinalizerFromGC()

Crash time: 2026-07-13 11:06:48 -0400.

We do not have the Browser Use lifecycle log needed to confirm whether registered debugger listener was the immediately preceding event, but the browser action and native crash signature match exactly.

A sanitized .ips report or the complete report can be provided through a private upload route. The raw report is not being posted publicly because it contains local identifiers and system metadata.

sethlazar · 6 days ago

I can confirm this exact crash remains reproducible on newer macOS Codex Desktop builds.

Observed 8 native crashes across:

  • 26.707.41301 (build 5103)
  • 26.707.51957 (build 5175)
  • 26.707.72221 (build 5307)

Every crash report has the same signature:

  • EXC_BAD_ACCESS (SIGSEGV)
  • KERN_INVALID_ADDRESS at 0x0000000000000548
  • Faulting thread: CrBrowserMain / main thread
  • Codex Framework, with v8impl::Reference::InvokeFinalizerFromGC() nearest the top frame

Correlating the app and crash logs, all 8 incidents occurred 1.51–4.40 seconds after Browser Use called browser.tabs.new(). Different destination pages produced the same result, so the failure does not appear site-specific.

The issue therefore persists in build 5307. The current workaround is to avoid the in-app browser and use external Chrome or headless browser automation.

Sanitized crash evidence can be supplied privately if maintainers need it; raw reports are not attached publicly because they contain local metadata.

omari58 · 5 days ago

Posted by Codex on behalf of the reporter.

Additional macOS reproduction on the same currently reported build.

Environment

  • ChatGPT/Codex Desktop: 26.707.72221 (build 5307)
  • macOS: 26.5.2 (25F84)
  • Hardware: Apple Silicon, Mac14,9

Reproduction evidence

Five native crashes occurred on July 15, 2026 at:

  • 12:00:47 +03:00
  • 12:02:44 +03:00
  • 12:03:56 +03:00
  • 12:13:42 +03:00
  • 12:25:06 +03:00

All five reports have the identical signature:

EXC_BAD_ACCESS (SIGSEGV)
KERN_INVALID_ADDRESS at 0x0000000000000548
Faulting thread: 0 CrBrowserMain / com.apple.main-thread
Top frame: Codex Framework!v8impl::Reference::InvokeFinalizerFromGC()

The top four crash frames are identical in all five reports.

App-log correlation

Each crash occurred approximately 0.5–1.5 seconds after Codex attached a new in-app browser WebView and it reached or approached dom-ready.

  • Four attempts opened https://public-wt2.localhost, reached Codex's generated ERR_SSL_PROTOCOL_ERROR page, and then crashed.
  • The fifth attempt created a fresh hidden Browser Use tab at about:blank and crashed immediately after the page was attached and mapped.
  • This control case indicates the crash is not specific to the destination site or TLS failure.
  • The logs also contain mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid.
  • One run logged No ChatGPT browser route is available for browser session before a fresh route/tab was created.
  • The desktop logs stop abruptly without a normal shutdown sequence.

Latest macOS incident identifier: A1AC2703-DDA6-44C8-BBF5-5B1B0F8800E8.

Full .ips reports and targeted app-log excerpts are available through a private upload route. Raw reports were not attached publicly because they contain local identifiers and filesystem/session metadata.

Panetes · 4 days ago

I can confirm the same native crash signature on a newer build.

Environment

  • ChatGPT/Codex Desktop: 26.707.91948 (build 5440)
  • macOS: 26.5.1 (25F80)
  • Apple Silicon

Reproduction

Browser Use created/opened an in-app browser tab for a local static HTML visual preview. The page contained no JavaScript, iframe, canvas, or WebGL content, and the preview server returned HTTP 200.

The browser operation then failed with:

native pipe is closed

The IAB backend disappeared afterward, and macOS generated a ChatGPT crash report at approximately 2026-07-16 12:47 local time.

Crash signature

EXC_BAD_ACCESS (SIGSEGV)
KERN_INVALID_ADDRESS at 0x0000000000000548
Faulting thread: 0 CrBrowserMain / com.apple.main-thread
Top frame: Codex Framework!v8impl::Reference::InvokeFinalizerFromGC()

This matches the signature reported here and confirms the issue remains reproducible in build 5440. Because the trigger page was a minimal static local page, the failure does not appear to depend on site JavaScript or complex page content.

The full .ips report is available if maintainers provide a private upload route. I am not attaching it publicly because it contains local identifiers and system metadata.

Panetes · 3 days ago

Retested on July 17, 2026 after updating both macOS and Codex:

  • Codex app: 26.715.21425 (build 5488)
  • macOS: 26.5.2 (25F84)
  • Apple Silicon (arm64)

I could not reproduce the crash on this build. Using the Codex in-app Browser Use path, I created fresh tabs and tested:

  1. This GitHub issue page
  2. about:blank
  3. https://example.com/
  4. A local static HTTP page with client-side JavaScript

Each tab attached and navigated successfully, remained accessible beyond the previously reported ~1–4.4 second crash window, and returned DOM state. The local page's live JavaScript uptime counter reached 5 seconds while the automation connection remained healthy.

There was one Codex restart between test passes, but it was deliberate to grant macOS Screen Recording permission—not a crash. A fresh in-app browser tab also passed after that restart.

So on this machine, #32399 appears fixed or at least is no longer reproducible on build 5488. I would avoid closing solely on this one result until other affected users confirm, but this is a positive data point.

omari58 · 2 days ago

Posted by Codex on behalf of the reporter as a follow-up to the previous build 5307 reproduction.

Retest result: no longer reproducible on build 5551

The same machine has now updated to:

  • ChatGPT/Codex Desktop: 26.715.31925 (build 5551)
  • macOS: 26.5.2 (25F84)
  • Hardware: Apple Silicon, Mac14,9

The built-in browser is enabled again; the effective feature state reports:

browser_use = true
browser_use_external = true
browser_use_full_cdp_access = true
computer_use = true
in_app_browser = true

The in-app browser was reopened against https://public-wt2.localhost/, the same destination involved in four of the five earlier build 5307 crashes. On build 5551:

  • the WebView attached successfully;
  • the page reached browser sidebar dom-ready;
  • the app remained alive beyond the previous approximately 0.5–1.5 second crash window;
  • the IAB backend subsequently initialized successfully; and
  • the reporter confirms the browser now appears to work normally.

No new matching ChatGPT/Codex native .ips report was found after the July 15 failure window.

This is a second positive data point after the build 5488 result already reported in this thread. On this previously affected machine, the crash appears fixed or is at least no longer reproducible in build 5551. This has not yet been treated as a long-duration soak test.