[macOS 27][26.915.31945] CrBrowserMain EXC_BAD_ACCESS after in-app browser tab handoff

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

ChatGPT/Codex Desktop 26.915.31945 (bundle build 9922). The crash report identifies Codex Framework / Chromium 153.0.8010.48.

What subscription do you have?

Unknown — the subscription tier is not present in the crash report or the local diagnostic metadata reviewed for this report.

What platform is your computer?

Darwin 27.0.0 arm64 arm

macOS 27.0 (26A428), Apple Silicon, MacBookPro18,1.

What issue are you seeing?

ChatGPT/Codex Desktop terminated with a native EXC_BAD_ACCESS on the Chromium browser main thread shortly after switching between two live Wix Editor webviews in the in-app browser sidebar.

Crash time: 2026-09-19 21:17:49.8825 +0700 / 2026-09-19 14:17:49.8825Z.

Sanitized crash signature:

Process: ChatGPT [32207]
Identifier: com.openai.codex
Version: 26.915.31945 (9922)
Code Type: ARM-64 (Native)

Triggered by Thread: 0 CrBrowserMain
Dispatch Queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS
                   (possible pointer authentication failure)
Termination Reason: SIGNAL, Code 11, Segmentation fault: 11
ARM exception: Data Abort, byte-read translation fault

The invalid address is unmapped. This is a native segmentation fault rather than a JavaScript exception or a macOS memory-pressure termination.

Top crash frames:

0   Codex Framework  cxxbridge1$slice$new + 125076
1   Codex Framework  v8::Object::Get(...) + 932
2   Codex Framework  v8::Object::Get(...) + 268
3   Codex Framework  ares_llist_replace_destructor + 1172156
4   Codex Framework  ares_llist_replace_destructor + 1357332
5   Codex Framework  ares_llist_replace_destructor + 953920
6   Codex Framework  ares_llist_replace_destructor + 958144
7   Codex Framework  ares_llist_replace_destructor + 1999408
8   Codex Framework  v8::Object::HasRealNamedProperty(...) + 257432
9   Codex Framework  v8::Object::HasRealNamedProperty(...) + 249936
10  Codex Framework  rust_exif$cxxbridge1$199$parse_exif + 33840
11  Codex Framework  rust_exif$cxxbridge1$199$parse_exif + 33188
12  Codex Framework  v8::internal::ThreadIsolation::WriteProtectMemory(...) + 107776
13  Codex Framework  v8impl::Reference::InvokeFinalizerFromGC() + 995320
14  Codex Framework  v8::StackTrace::CurrentScriptData(...) + 81164
15  Codex Framework  v8impl::Reference::InvokeFinalizerFromGC() + 994184

The large symbol offsets suggest that several names are nearest exported symbols rather than exact internal functions. Framework UUID and top image offsets for vendor symbolication:

Codex Framework UUID: 4c4c4425-5555-3144-a170-ac9d62c2099a
Framework version: 153.0.8010.48
Top image offsets:
413012, 1869252, 1868588, 75366536, 75551712, 75148300,
75152524, 76193788, 13100872, 13093376, 40610096, 40609444,
3207232, 60735336, 2744388, 60734200

Incident identifier: 7E642C7F-D15E-4042-985F-55B0E9FBF6E4.

What steps can reproduce the bug?

This sequence is inferred from the app log and has not been deliberately reproduced:

1. Open Wix Studio/Editor in the Codex in-app browser sidebar.
2. Have two live Wix webviews in the same sidebar thread.
3. Switch from the first browser tab to the second, then back while the editor is loading.
4. The incoming webview reaches dom-ready.
5. The main ChatGPT/Codex process may terminate a few seconds later with EXC_BAD_ACCESS on CrBrowserMain.

The sanitized event correlation is:

14:17:39.452Z  staged webview handoff to browser tab A
14:17:39.512Z  committed handoff to tab A
14:17:39.532Z  released outgoing handoff

14:17:42.315Z  staged handoff from tab A to browser tab B
14:17:42.626Z  committed handoff to tab B
14:17:42.631Z  backgrounded tab A webview
14:17:42.633Z  released outgoing handoff

14:17:46.181Z  Wix Editor webview reported DOM-ready
14:17:49.882Z  native app crash

The crash occurred approximately 3.70 seconds after the final Wix Editor dom-ready event. There was no browser sidebar guest torn down or window-close event in the final sequence.

What is the expected behavior?

Switching, backgrounding, or reattaching embedded browser tabs should not terminate the main application. A stale or failed webview should be discarded or surfaced as a recoverable browser error while the task and desktop application remain usable.

Additional information

This appears related to the broader in-app-browser native lifetime-crash family but is not an exact duplicate of the closest reports found:

• #32399 reported EXC_BAD_ACCESS / CrBrowserMain / InvokeFinalizerFromGC() shortly after Browser Use debugger attachment. It was closed after the crash stopped reproducing on July builds. This occurrence is on build 9922, follows a visible tab handoff, and has a different fault address and top-frame sequence.
• #45159 reports a pointer-authentication SIGSEGV immediately after browser guest teardown and window-close notification frames. This occurrence has no teardown or NSWindow _close event in its final sequence.
• #45325 reports a CrBrowserMain pointer-authentication crash after Retry from an already-broken UI state. This occurrence followed live browser-tab handoffs instead.
• #26863 is an older open navigation-related in-app-browser crash with EXC_BREAKPOINT, not this EXC_BAD_ACCESS signature.

The process had been running for approximately 6 hours 27 minutes. It was native ARM64, SIP was enabled, and the crash report records zero external task_for_pid, thread_create, or thread_set_state activity targeting the process.

The complete .ips report and matching desktop log are available privately. They are not attached publicly because they contain stable device identifiers, local paths, conversation/browser identifiers, and Wix editor/session URLs. A privately submitted feedback/session ID can be added if one is generated from the app.

The macOS crash report was correlated with the matching desktop log. No intentional crash reproduction was performed.

Start with the matching desktop log and sanitized .ips crash report, focusing on the CrBrowserMain frames and the staged, committed, and released webview handoff sequence. Compare the related issues listed in the report and use vendor symbolication for the provided Codex Framework offsets; done means identifying a reproducible lifetime failure or a confirmed fix that keeps tab switching from terminating the application.