›_ Codex Issues
Codex Issues / #38867

[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

Open 💬 4 comments Opened Aug 16, 2026 by StefanoWoo
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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)

| Time | Event |
|---|---|
| 12:28 | App launch on framework .76-era build; resumes last thread normally; runs ~1.5 h without issues |
| 14:11:24 | App bundle self-updates; Frameworks/Codex Framework.framework/Versions/ now contains only 151.0.7922.137 |
| 14:12:45 | First crash |
| 14:12–14:18 | 5 crashes in 6 minutes (relaunch loop), then process stays down |
| 14:27, 14:29, 14:34 | Manual relaunches; identical crash each time |

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 11 days ago

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

  • #38566

Powered by Codex Action

meet-cjli · 11 days ago

Same here — identical crash loop on my machine today.

## Environment

  • macOS 26.5.1 (25F80), Apple Silicon (Mac16,10, 32 GB RAM)
  • ChatGPT desktop app 26.810.52044 (build 6662), bundle com.openai.codex
  • Codex Framework 151.0.7922.137

## Crash signature (identical, 20+ occurrences today)

abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
reading_mode$cxxbridge1$194$parse_distilled_html
reading_mode$cxxbridge1$194$parse_distilled_html
v8::CppHeap::CollectGarbageInYoungGenerationForTesting(...)

Faulting thread alternates between V8Worker and computer-use. Every instance
aborts ~2 minutes after launch. The app was fine before today — the crash loop
started 2026-08-16, matching the reporter's timeline.

## What I ruled out (same conclusion: server-side content)

  • System memory pressure — crashed with 9 GB free
  • Local caches — cleared Cache, Code Cache, Local Storage, Session Storage in both Default and Partitions/codex-browser-app: no effect
  • Local threads — deleted/quarantined suspect conversations, including 415 MB and 390 MB rollout files: no effect
  • Heartbeat automation — disabled a weekly web-research automation: no effect
  • Full bisect: fresh profile + no ~/.codex (logged out) → stable 4+ minutes. Any configuration with the account logged in → crash within ~2 minutes, even with ~/.codex stripped

to just auth.json + config.toml

  • During the memory climb (~0.5 GB → 2.5+ GB over ~90 s) there is a persistent HTTPS connection to a Cloudflare edge IP — the poisoned content is downloaded from my account state after

login

  • Raising the V8 heap via NODE_OPTIONS does not help — the OOM happens in a Node worker thread with its own resourceLimits

I have 20+ from today alone.

+1 on the asks: poison-pill handling around parse_distilled_html, and a
safe-mode launch flag that skips resuming the previous thread.

ApexAspire · 6 days ago

Confirming this is still live on a newer framework and app build — crash loop started here today, minutes after a framework self-update.

Environment

  • macOS 26.5.1 (25F80), Apple Silicon (Mac16,10, 24 GB RAM)
  • ChatGPT desktop app 26.818.41705 (build 6971), bundle com.openai.codex
  • Codex Framework 151.0.7922.170 — self-updated 2026-08-22 ~04:37 local (BST). Frameworks/Codex Framework.framework/Versions/ contains only .170.
  • App bundle itself dates from 2026-07-24 — only the framework changed this morning.

Timeline (all local, 2026-08-22)

| Time | Event |
| --- | --- |
| 04:37–04:47 | Framework self-update to 151.0.7922.170 |
| 09:08, 09:43, 10:22, 11:32 | 4 crashes, all identical signature |

Zero ChatGPT crash reports on this machine before today.

Crash signature (all 4 reports)

EXC_CRASH / SIGABRT, abort() from the app itself. Faulting thread is computer-use in 3 reports and V8Worker in 1 — matching the reporter and @meet-cjli:

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(...)

One nuance: the 09:43 report has the same parse_distilled_html frames and the same computer-use thread but no OOMErrorHandler frame near the top — same path, possibly a slightly different failure mode within it.

Not system memory pressure here either — machine had free pages at crash time; this is the V8 heap limit inside the worker, as @meet-cjli characterized.

So: whatever regressed in .137 is still present in .170, on the current public app build. Happy to attach the full .ips files if useful.

ApexAspire · 6 days ago

Follow-up bisect data point from the same machine as my comment above: the ChatGPT Classic app is stable on the same account.

  • /Applications/ChatGPT Classic.app — bundle com.openai.chat, version 1.2026.184 (build 1784145287)
  • Same macOS 26.5.1 machine, same OpenAI account, running fine alongside the crashing unified app (it just lacks the Work/Codex surface)

Combined with @meet-cjli's logged-out-stability result, this narrows it further: the account's server-side state isn't inherently toxic — the content only aborts the process when the unified app's Codex Framework reading-mode pipeline parses it. Classic (which never had that pipeline) is unaffected.

Also noting for other affected users landing here: Classic appears to still be obtainable and works as a chat-only stopgap until the framework fix ships.