[app][macOS][26.810.52044] Hard crash loop after 151.0.7922.137 framework self-update: V8 OOM in reading_mode parse_distilled_html on every launch

Summary

After the desktop app self-updated at 14:11 local time today (Codex Framework 151.0.7922.76 → 151.0.7922.137, app version 26.810.52044 build 6662), it entered a hard crash loop on macOS: every launch aborts within ~60–90 seconds with a V8 heap OOM (SIGABRT) in the reading-mode HTML distillation parser. The app is unusable — 8 identical crashes today, across a fresh relaunch each time.

The same account state ran fine for ~1.5 hours on the previous framework earlier the same day, so this looks like a regression introduced by the .137 framework, not corrupted user data.

Environment

• macOS 15.x (Darwin 25.5.0), Apple Silicon
• ChatGPT desktop app 26.810.52044 (build 6662), bundle com.openai.codex
• Codex Framework 151.0.7922.137 (self-updated 2026-08-16 14:11 local)
• Previous framework 151.0.7922.76 (installed 2026-08-12) — no crashes

Crash signature

Consistent across all 8 crash reports (EXC_CRASH / SIGABRT, faulting thread):

libsystem_kernel.dylib   __pthread_kill
libsystem_pthread.dylib  pthread_kill
libsystem_c.dylib        abort
Codex Framework          node::OOMErrorHandler(char const*, v8::OOMDetails const&)
Codex Framework          reading_mode$cxxbridge1$194$parse_distilled_html
Codex Framework          reading_mode$cxxbridge1$194$parse_distilled_html
Codex Framework          v8::CppHeap::CollectGarbageInYoungGenerationForTesting(cppgc::EmbedderStackState)
...
Codex Framework          node::WorkerThreadsTaskRunner::WorkerThreadsTaskRunner(...)

Node OOM → abort() in the embedded Node/V8 layer while reading_mode … parse_distilled_html is on the stack.

Timeline (all times local, 2026-08-16)

What I ruled out (all checked before filing)

• Local session stub: the thread the app resumes at startup (thread/resume in logs) has only a 42 KB local rollout .jsonl. Quarantining it (moving it out of ~/.codex/sessions/) does not stop the crash — the parsed content appears to come from the server-side thread state.
• Browser partition state: Partitions/codex-browser-app had no writes in the hours before the first crash; Session Storage is ~24 KB; IndexedDB ~16 KB. Clearing candidates found nothing to clear.
• Profile / window-restore state: the resumed conversation ID appears nowhere under Application Support/Codex/Default, Local State, or Saved Application State.
• Stale processes: killed a leftover codex_chronicle from a crashed instance that was holding the app-server sidecar lock (log: Waiting to acquire lock (owned by pid=…)), which had the app's IpcRouter re-spawning every ~150 ms (220+ per-thread log files within one minute of launch). Cleaning this up did not affect the crash either.

Additional observations

• During the lock contention described above, one instance created 220+ thread log files in under a minute (~/Library/Logs/com.openai.codex/.../...-t0 through -t221), all but t0 empty. Possibly a secondary bug worth a look: the sidecar lock holder from a crashed instance is never reaped, and the new instance thrashes instead of failing over.
• Possibly related existing reports: #33582 (memory grows to 55 GB), #32769 (crash when starting a new task) — but those predate .137; this one is a hard startup loop that began at the minute of the framework update.

Expected behavior

If reading-mode distillation of a restored thread's content exceeds the heap, the app should skip/fail that one parse (poison-pill handling) instead of aborting the whole process — the current behavior makes the app permanently unusable with no user-visible error and no way to recover from inside the app.

Ask

• Poison-pill handling around parse_distilled_html (bound the input size or catch the OOM path).
• A way to launch without resuming the previous thread (safe-mode flag), so users can recover without filesystem surgery.

Happy to provide the full .ips crash reports or run a debug build — the crash reproduces 100% on this machine.

Begin with the reading_mode...parse_distilled_html crash path and the thread/resume startup flow, using the supplied crash reports and framework-version comparison. Completion means safely handling the failing parse and providing a launch path that skips restoring the prior thread, with verification that the app no longer enters the repeated crash loop.