[macOS] Desktop app crashes with EXC_BAD_ACCESS in Codex Framework V8 path

Open 💬 2 comments Opened Jul 18, 2026 by dimasyankauskas

💡 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?

26.715.31925 (build 5551)

What platform are you using?

macOS 26.5.2 on Apple Silicon (ARM64)

What issue are you seeing?

The Codex desktop app has crashed four times in the last two days, including after a long-running session.

macOS recorded EXC_BAD_ACCESS (SIGSEGV) with KERN_INVALID_ADDRESS. The crashing thread was the main browser/UI thread (CrBrowserMain). The visible stack frames were inside Codex Framework, including V8/JavaScript-runtime functions such as v8impl::Reference::InvokeFinalizerFromGC and v8::internal::ThreadIsolation::TryLookupJitPage.

This was a native segmentation fault, not an out-of-memory termination or a network error.

Steps to reproduce

I do not yet have a reliable minimal reproduction. The crashes occurred during normal desktop-app use, including after the app had remained open for several hours.

Expected behavior

The desktop app should remain stable during extended normal use.

Additional information

I have intentionally omitted the full crash report and all unique identifiers, local paths, workspace details, account information, and timestamps to avoid publishing personal data. I can provide a sanitized or full crash report privately if a maintainer requests it.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#33733

Powered by Codex Action

Nickz22 · 7 days ago

I hit the same native crash signature on a newer build. Adding this as current corroborating evidence rather than opening a duplicate.

Environment

ChatGPT/Codex desktop: 26.818.22352 (build 6872)
Codex Framework: 151.0.7922.170
macOS: 26.5.1 (25F80)
Architecture: Apple Silicon (arm64, not translated)

Occurrence

Crash time: 2026-08-20 22:52:45 PDT
App launch time: 2026-08-20 20:47:05 PDT (about 2h 6m uptime)
macOS crash incident ID: 38BDBB70-30D2-4D6E-8CAA-6DAFFB99CAAF
Termination: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS, signal 11
Faulting thread: CrBrowserMain / com.apple.main-thread
Faulting address: 0x1beffed77baffede

Top symbolicated frames:

v8::Object::GetCreationContextChecked(v8::Isolate*)
uv_req_get_type
uv_req_get_type
ares_llist_replace_destructor
v8::ScriptCompiler::CompileModule(...)
v8::ScriptCompiler::Compile(...)
v8::Isolate::SetIsInputHandling(bool)
cppgc::internal::PersistentRegion::IsCreationThread()
cxxbridge1$string$drop
v8impl::Reference::InvokeFinalizerFromGC()

The crash report's kernel triage section also records two VM Fault hit memory shortage events. macOS did not report a jetsam/OOM termination; the recorded terminal cause is the invalid-address segmentation fault, so memory pressure may be contributory but is not proven as the root cause.

This occurred during normal extended use and was not intentionally triggered. The app restarted successfully afterward. I have one .ips report and the corresponding desktop logs, but have not posted them publicly because they contain unique identifiers and potentially sensitive local context. I can provide a reviewed/sanitized report if a maintainer identifies a safe private intake route.