Codex App main process SIGSEGV after Browser Use IAB sidebar teardown
What version of the Codex App are you using (From About Codex dialog)?
26.513.31313, build 2867.
The packaged Crashpad command also reported Electron 42.0.1.
What subscription do you have?
ChatGPT account in Codex App. Exact plan omitted from this public report.
What platform is your computer?
Darwin 25.4.0 arm64 arm
macOS 26.4.1, build 25E253.
What issue are you seeing?
Codex App crashed completely. This was not just a renderer reload or a Browser Use command failure: macOS reported the Codex Desktop main process exiting with SIGSEGV.
Sanitized system log evidence:
2026-05-18 15:28:30.931 AMFI: Denying core dump for pid 740 (Codex)
2026-05-18 15:28:30.933 chrome_crashpad_handler: mach_vm_read(...): (os/kern) invalid address (1)
2026-05-18 15:28:31.426 launchd: [application.com.openai.codex ... [740]:] exited due to SIGSEGV | sent by exc handler[740]
2026-05-18 15:28:31.469 ControlCenter: Process exited: status domain:signal(2) code:SIGSEGV(11)
2026-05-18 15:28:31.482 loginwindow: kLSNotifyApplicationAbnormalDeath, app must have crashed
There was no useful crash artifact available locally after the crash:
- the Codex Crashpad directory contained only
settings.dat - no matching Codex
.ipscrash report was present in DiagnosticReports - macOS denied the core dump
The strongest app-log correlation immediately before the native crash is Browser Use / in-app-browser lifecycle churn. In the old main-process desktop log, one Browser Use conversation emitted a very large number of route-resolution events, then its browser sidebar guest was torn down shortly before the SIGSEGV:
2026-05-18T07:25:30.388Z IAB_LIFECYCLE registered debugger listener ... conversationId=<redacted-conversation> webContentsId=4
2026-05-18T07:27:26Z-07:28:13Z many repeated IAB_LIFECYCLE resolved browser use route entries for the same conversation/window/turn
2026-05-18T07:28:13.657Z warning [browser-session-registry] IAB_LIFECYCLE browser sidebar guest torn down conversationId=<redacted-conversation> guestWebContentsId=4 windowId=1
2026-05-18T07:28:13.657Z info [browser-use-iab-api] IAB_LIFECYCLE unregistered debugger listener reason=webcontents-destroyed ... webContentsDestroyed=true webContentsId=4
2026-05-18T07:28:23.559Z info [browser-sidebar-manager] browser sidebar console message ... message="[vite] server connection lost. Polling for restart..." sourceId=http://127.0.0.1:4321/@vite/client
2026-05-18T07:28:30.931Z native SIGSEGV reported by macOS
Counts from the same desktop log:
IAB_LIFECYCLE resolved browser use route: 26353
same conversation route-resolution entries: 23230
browser sidebar guest torn down: 1
webcontents-destroyed unregister: 1
Vite server connection lost console messages: 64
The server connection lost messages came from local webview console output and may only be a symptom of the teardown/reload state. The crash signature itself is the main Electron/Codex process SIGSEGV.
What steps can reproduce the bug?
I do not yet have a minimal deterministic repro, but this is the observed sequence:
- Run Codex App 26.513.31313 on macOS arm64.
- Use Browser Use with the in-app browser against local localhost development pages over a long Desktop session.
- Let several Browser Use turns connect and disconnect from the in-app browser.
- In the failing run, the same Browser Use conversation repeatedly resolved the same IAB route thousands of times.
- The browser sidebar guest for that conversation was torn down and the debugger listener was unregistered because the webContents was destroyed.
- A few seconds later, the Codex Desktop main process crashed with SIGSEGV.
What is the expected behavior?
The in-app browser and Browser Use route lifecycle should recover from sidebar guest teardown, local dev-server reconnects, and stale webContents destruction without crashing the Codex Desktop main process.
At minimum, Browser Use should fail gracefully with a structured error and leave the app alive.
Additional information
This looks related to the Browser Use / IAB lifecycle class tracked in #22172, but this report is for a hard native main-process crash rather than only an in-app browser hang or discovery failure.
I inspected the open-source repository and could not find the packaged Desktop Browser Use/IAB implementation strings such as browser-session-registry, browser-use-iab-api, or IAB_LIFECYCLE, so I do not have a source-level patch to propose from this checkout.
Root-cause confidence from local evidence:
- high confidence: the immediate crash was a native Codex main-process SIGSEGV
- medium confidence: the trigger was related to Browser Use / IAB webContents lifecycle handling after sidebar guest teardown
- low confidence: the exact native function can be identified without a minidump, core file, or source for the packaged Desktop IAB implementation
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for the duplicate check. I reviewed #22172 and I do not think this is a duplicate.
#22172 reports an in-app browser / Browser Use hang where the app remains alive and the webview becomes stale after bridge disconnects. This issue reports a harder failure mode: macOS recorded the Codex App main process exiting with SIGSEGV(11), followed by an abnormal app death notification.
The IAB lifecycle logs look related, so #22172 is useful prior art, but the observed failure and diagnostic evidence are different: #22172 is a recoverability/hang issue inside a running app, while this issue is a native main-process crash. I would keep this open as a separate crash report unless maintainers prefer to consolidate all IAB lifecycle failures under one tracking issue.
I’m seeing what looks like the same crash class on Codex App 26.513.31313 on macOS/Darwin arm64.
A recent crash on 2026-05-19 showed a hard Codex Desktop process crash, not just a Browser Use failure or renderer reload. macOS unified logs included:
application.com.openai.codex ... exited due to SIGSEGVProcess exited ... domain:signal(2) code:SIGSEGV(11)kLSNotifyApplicationAbnormalDeath, app must have crashedCrashpad also logged:
chrome_crashpad_handler ... mach_vm_read(...): (os/kern) invalid address (1)I did not find a useful local crash artifact: DiagnosticReports had no Codex crash report, and the Codex Crashpad directory only contained
settings.dat.The Codex desktop log for the affected process showed Browser Use / IAB activity against a local Vite app at
http://127.0.0.1:5173/. In that process I saw hundreds ofIAB_LIFECYCLE resolved browser use routeentries, Vite console messages from@vite/client, and the same lifecycle pattern:IAB_LIFECYCLE browser sidebar guest torn downIAB_LIFECYCLE unregistered debugger listener ... reason=webcontents-destroyed ... webContentsDestroyed=trueIn my latest crash the teardown line was earlier in the same process rather than immediately adjacent to the SIGSEGV, so I’d classify this as likely the same Browser Use / IAB webContents lifecycle crash class rather than a deterministic minimal repro.
I just reproduced what looks like the same IAB/sidebar teardown crash class.
Environment:
26.519.81530, build317842.1.00.133.026.5, arm64User-visible behavior: Codex Desktop crashed/restarted while using/opening the in-app browser, with multiple chats/browser panes active.
Fresh evidence from the latest event:
.crash/.ipsreport was written.settings.dat; no pending/completed minidump.status=ok,errors=0; queue was empty.2026-05-28T14:45:28Z.2026-05-28T14:45:38ZwithLaunching app ... packaged=true platform=darwin.IAB_LIFECYCLE resolved browser use route: 7022browser sidebar guest torn down: 1webContentsDestroyed=true: 1Final relevant sanitized log sequence:
This overlaps with #24458 because I had multiple in-app browser panes/chats active, but the immediate log shape is much closer to this issue: Browser Use / IAB webContents lifecycle churn followed by a full app restart.