Codex Desktop CrBrowserMain EXC_BAD_ACCESS in v8::Object::GetCreationContext() after Retry from broken UI state

What happened?

Codex Desktop crashed natively on macOS while attempting to recover from an already-broken UI state.

The process had been running for several days. It was already exhibiting the packaged-resource failure documented in #37551 / electron/electron#52804, where some ASAR-backed resources could no longer be loaded because Electron retained a cached path to a temporary extracted file that had since disappeared.

• #37551
  • electron/electron#52804

While an existing Codex window was still loaded, I attempted to use the in-app search feature. That reached the usual "Something went wrong" fallback/error state. I then clicked Retry / Try Again.

On previous occurrences of the packaged-resource failure, Retry has sometimes returned to the already-open chat. In this occurrence, the entire app exited with a native crash instead.

I don't have enough evidence to say the stale-ASAR state caused the native crash. I'm reporting the crash separately because the failure mode itself appears distinct and may represent a renderer/V8-context lifetime issue exposed by the recovery/reload path.

Crash signature

Sanitized excerpt from the macOS crash report:

Triggered by Thread: 0  CrBrowserMain
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS
                  (possible pointer authentication failure)
Termination: Segmentation fault: 11

Thread 0 Crashed:: CrBrowserMain
0  Codex Framework  v8::Object::GetCreationContext() + 36

Nearby frames include V8/browser-process code in the areas of:

v8::ScriptCompiler::CachedDataVersionTag()
v8::ValueSerializer::ValueSerializer(...)
v8impl::Reference::InvokeFinalizerFromGC()

The faulting address was unmapped and the CPU reported a byte-read translation fault.

Environment

Codex Desktop: 26.901.51231 (8109)
Codex Framework / Chromium: 152.0.7977.64
Architecture: arm64
macOS: 26.6

Possibly related observations

The same long-running process had accumulated 38 threads named NetworkConfigWatcher by the time of the crash.

That resembles the long-running-process behaviour reported in #33058, although that issue reports EXC_BREAKPOINT / SIGTRAP, so this is not an exact crash-signature match.

• #33058

There are also some broadly similar CrBrowserMain / V8 code-cache/finalizer crash stacks in #32676:

• #32676

Again, that issue reports SIGTRAP rather than this EXC_BAD_ACCESS / SIGSEGV, so I am only cross-referencing it as potentially related native/V8 lifecycle behaviour.

Observed sequence

long-running Codex process
→ stale/deleted ASAR extraction leaves some packaged resources unloadable
→ existing window remains partially usable
→ another UI action reaches the fallback/error state
→ Retry / recovery is attempted
→ native CrBrowserMain EXC_BAD_ACCESS in v8::Object::GetCreationContext()

I would treat that sequence as an observation rather than a demonstrated causal chain.

The ASAR issue explains why the UI was already in a broken state, but the subsequent native crash may be a separate renderer/V8-context lifetime bug exposed by retry/reload, or it may be unrelated.

Expected behavior

Retrying or reloading from a UI/resource-loading failure should not terminate the entire Codex Desktop process with a native V8 crash.

Additional information

I have the full macOS crash report from this occurrence but have not attached it publicly because it contains machine-specific details. I can provide a sanitized copy or additional sanitized excerpts if useful.

Start with the full sanitized macOS crash report and the CrBrowserMain stack, then compare the V8-related frames with #33058 and #32676 and the recovery/resource context in #37551. Establish whether Retry after the broken UI state can reproduce the native crash; done means recovery no longer terminates the Codex Desktop process with EXC_BAD_ACCESS.