[macOS][26.825.41651] Codex/ChatGPT app crashes with EXC_BREAKPOINT (SIGTRAP) in CrBrowserMain

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

26.825.41651 (build 7345). The About dialog identifies the app as ChatGPT — Powered by Codex & OWL and shows a release date of Aug 28, 2026.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

• macOS 26.6.2 (25G83)
• MacBook Pro 16-inch (Mac17,6)
• Apple M5 Max
• ARM64 native
• 128 GB RAM
• System Integrity Protection enabled

What issue are you seeing?

While I was actively using Codex in the macOS desktop app, the entire application suddenly terminated. macOS then displayed the system crash dialog: “ChatGPT quit unexpectedly.”

This was not an ordinary model/session error inside the UI. The desktop process itself exited, interrupting the active Codex workflow and requiring the application to be reopened.

Crash metadata from the Apple report:

Process:             ChatGPT [27688]
Path:                /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
Identifier:          com.openai.codex
Version:             26.825.41651 (7345)
Code Type:           ARM-64 (Native)
Role:                Background

Date/Time:           2026-08-30 01:35:40.5906 -0400
Launch Time:         2026-08-28 13:54:57.1247 -0400
Hardware Model:      Mac17,6
OS Version:          macOS 26.6.2 (25G83)
Incident Identifier: 8C268BE3-14F9-4FCF-A338-E36252FD9F85

Triggered by Thread: 0  CrBrowserMain, Dispatch Queue: com.apple.main-thread
Exception Type:      EXC_BREAKPOINT (SIGTRAP)
Exception Codes:     0x0000000000000001, 0x000000011920a570
Termination Reason:  Namespace SIGNAL, Code 5, Trace/BPT trap: 5

Top of the crashed stack:

Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0   Codex Framework  ares_llist_replace_destructor + 21568
1   Codex Framework  ares_llist_replace_destructor + 21460
2   Codex Framework  reading_mode$cxxbridge1$194$parse_distilled_html + 13220156
3   Codex Framework  reading_mode$cxxbridge1$194$parse_distilled_html + 13220036
4   Codex Framework  v8::Object::SetLazyDataProperty(...) + 189088
5   Codex Framework  v8impl::Finalizer::ResetEnv() + 34688
6   Codex Framework  v8::ScriptCompiler::Compile(...) + 56920
7   Codex Framework  v8::ArrayBuffer::NewBackingStore(...) + 226736
8   Codex Framework  v8::ArrayBuffer::NewBackingStore(...) + 222600
9   Codex Framework  v8::ArrayBuffer::NewBackingStore(...) + 221784

The stack therefore appears to pass through the Chromium browser main thread, the reading-mode parse_distilled_html bridge, and V8. This is only an observation from the crash report, not a definitive root-cause claim.

What steps can reproduce the bug?

1. Launch the current macOS ChatGPT/Codex desktop app, version 26.825.41651.
2. Open and actively use a Codex session normally.
3. During use, the app may suddenly terminate without an in-app error or warning.
4. macOS displays the “ChatGPT quit unexpectedly” crash reporter.

The precise action that triggered the crash is currently unknown because the application exited immediately. I have observed this crash at least once; the exception and stack signature above may be the most useful reproduction clue.

What is the expected behavior?

The desktop app should remain running during a Codex session. If an internal browser, reading-mode, renderer, or V8 operation fails, the failure should be contained and should not terminate the entire application or interrupt the active workflow.

Additional information

• Codex Framework version in the crash report: 151.0.7922.174.
• The app had been running since Aug 28, 2026 at 13:54:57 -0400 before crashing on Aug 30 at 01:35:40 -0400.
• The Apple report contains the complete thread list, ARM thread state, binary images, and system configuration. I retained the full approximately 228 KB crash report and can provide it if needed.
• Screenshots were captured of the macOS crash dialog, the app About dialog, and the Mac hardware/OS information.
• Privacy-sensitive values such as the Mac serial number, device identifiers, and crash reporter key have intentionally been omitted from this public issue.

Start with the retained Apple crash report and the Thread 0 CrBrowserMain stack, especially the reading-mode parse_distilled_html and V8 frames. The precise triggering action is unknown and no source file or test is identified. Done means reproducing or isolating the crash and keeping the macOS app running when the internal browser, reading-mode, or V8 operation fails.