Updated Codex Always Crash!!!

Additional repro data from another machine, matching this issue's git worker / Node-V8 OOM signature.

Environment:

• Codex App: 26.601.21317 (build 3511)
• Platform: Darwin 25.5.0 arm64 arm
• macOS: 26.5 (25F71)
• Hardware model in crash report: Mac14,15
• Crash type: EXC_CRASH / SIGABRT
• Termination: Abort trap: 6

Crash reports from 2026-06-03:

| capture time | incident | faulting thread | thread name | top frames |
| --- | --- | --- | --- | --- |
| 10:46:46.3957 +0200 | C89978CA-F230-4CF4-8849-93655679E278 | 49 | git | __pthread_kill -> pthread_kill -> abort -> node::OOMErrorHandler(...) -> v8::ToExternalPointerTag(...) |
| 10:56:43.8075 +0200 | 97FD07E1-6916-424A-B4DC-E4B4BDB5798C | 49 | git | __pthread_kill -> pthread_kill -> abort -> node::OOMErrorHandler(...) -> v8::ToExternalPointerTag(...) |
| 11:14:57.9655 +0200 | 819151A8-6EBA-4CFD-9074-4F0A12F224C1 | 49 | git | __pthread_kill -> pthread_kill -> abort -> node::OOMErrorHandler(...) -> v8::ToExternalPointerTag(...) |

Representative crashed-thread stack from the latest report:

Thread 49 Crashed:: git
0  __pthread_kill
1  pthread_kill
2  abort
3  node::OOMErrorHandler(char const*, v8::OOMDetails const&)
4  v8::ToExternalPointerTag(unsigned short)
5  v8::ToExternalPointerTag(unsigned short)
6  v8::internal::OptimizingCompileTaskExecutor::RunCompilationJob(...)
...
28 uv_run
29 node::SpinEventLoopInternal(node::Environment*)
30 node::worker::Worker::Run()
31 node::worker::Worker::SelfSize() const

Impact: the whole Codex desktop app exits unexpectedly. This supports the root-cause hypothesis that a Node/V8 OOM in the desktop app's git worker aborts the entire app process instead of the worker failing or restarting in isolation.

Repro status: not tied to a single deterministic command yet. It happened repeatedly during normal Codex App use in one morning/session, with no user-facing error before the app terminated.

My report was #26458. Yes, this appears to be the same underlying crash signature as #26079: Codex Desktop 26.601.21317, triggered thread git, SIGABRT, node::OOMErrorHandler. My issue may add a reproduction clue: it occurs after invoking Computer Use, and my crash reports include browser-use-peer-authorization.node. I’m okay closing my issue as a duplicate if you want to track the core Node/V8 git-worker OOM in #26079, but I recommend noting the Computer Use/browser-use trigger there.

Also reproducing on the latest build 26.602.30954 (build 3575) — not memory-size dependent

Same signature as the report: EXC_CRASH / SIGABRT (code 6), faulting thread named git, stack top node::OOMErrorHandler(...) → abort() (Node/V8 JS-heap OOM inside a worker thread).

• App: Codex Desktop, com.openai.codex
• Hardware: Mac, 36 GB RAM (so 24 GB isn't the cause — plenty of free system memory at crash time)
• Crash pattern: 14/14 recent crash reports (2026-06-03 → 06-05) all triggered_thread=git, node_oom=true
• Versions affected: 26.601.21317 (3511) and the newest 26.602.30954 (3575)
• Trigger: consistently fires at task completion (end of a turn)

Latest stack (symbolicated, faulting thread git):

abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
v8::internal::OptimizingCompileTaskExecutor::RunCompilationJob(...)
...
node::worker::Worker::Run()

Looks like the git worker's V8 isolate hits its old-space heap limit and V8 aborts the whole process. Happy to share full .ips files if useful.

Maybe we should as CODEX to fix it.

Confirming this is still happening on today's latest production build
(26.623.42026 / build 4514, published on the production appcast
https://persistent.oaistatic.com/codex-app-prod/appcast.xml at
2026-06-27 04:58 UTC). Same git-worker / node::OOMErrorHandler /
abort() signature as the original report — nothing was fixed in the
4 builds shipped between 2026-06-21 and 2026-06-27.

Adds these 4 new affected builds to the timeline

| Date (local) | App version | Build | Signal | V8 OOM in faulting frame? | Uptime (h) | Wake (h) |
|---|---|---|---|---|---|---|
| 2026-06-21 | 26.602.30954 | 3575 | SIGABRT | yes | 23.3 | 1.9 |
| 2026-06-21 | 26.602.30954 | 3575 | SIGABRT | yes | 23.3 | 2.0 |
| 2026-06-21 | 26.602.30954 | 3575 | SIGABRT | yes | 23.3 | 2.1 |
| 2026-06-21 | 26.602.30954 | 3575 | SIGABRT | yes | 23.6 | 2.2 |
| 2026-06-21 | 26.602.30954 | 3575 | SIGABRT | yes | 24.2 | 2.8 |
| 2026-06-21 | 26.616.41845 | 4198 | SIGABRT | yes | 24.4 | 3.2 |
| 2026-06-21 | 26.616.51431 | 4212 | SIGABRT | yes | 33.3 | 13.4 |
| 2026-06-24 | 26.616.81150 | 4306 | SIGTRAP† | (V8 fatal — see note) | 77.8 | 0.8 |
| 2026-06-27 | 26.623.42026 | 4514 | SIGABRT | yes | 130.6 | 15.5 |

† Incident 8 is SIGTRAP rather than SIGABRT, still in the same git
worker. Consistent with a V8 fatal-error path taken when the OOM-handler
path itself fails or an internal V8 invariant is violated during
late-stage allocation. Same root cause family.

Identical signature across all 9 incidents

Exception Type   : EXC_CRASH (SIGABRT)
Termination      : SIGNAL, Code 6, "Abort trap: 6"
ASI              : abort() called
Faulting thread  : <name="git">

Top frames:
  0   libsystem_kernel.dylib   __pthread_kill + 8
  1   libsystem_pthread.dylib  pthread_kill + 296
  2   libsystem_c.dylib        abort + 124
  3   Codex Framework          node::OOMErrorHandler(char const*, v8::OOMDetails const&) + 344
  ...
  26  Codex Framework          node::InternalCallbackScope::Close + 400
  27  Codex Framework          node::InternalMakeCallback(...) + 464
  28  Codex Framework          node::AsyncWrap::MakeCallback(...) + 280
  29  Codex Framework          node::HandleWrap::OnClose(uv_handle_s*) + 496
  30  Codex Framework          uv_run + 528
  31  Codex Framework          node::SpinEventLoopInternal(node::Environment*) + 432
  32  Codex Framework          node::worker::Worker::Run() + 4712

Environment (constant across all 9)

• macOS 26.2 (build 25C56), Apple Silicon, Mac16,5
• No Computer Use feature used during any of the 9 crashes (so the

browser-use-peer-authorization.node path mentioned in #26458 is not
required to trigger this — it's just one of several entry points into
the git worker that exhausts the heap)

Why the wake-h column matters

The time-since-wake at crash spans 0.8 h → 15.5 h, which makes this look
workload-driven rather than time-driven. Combined with 7 crashes inside a
few hours on 2026-06-21 across 3 auto-updated builds, the most likely
culprit is an unbounded retained data structure inside the git Node
Worker — a result cache / EventEmitter listener chain / Map keyed on
repo path or commit SHA that is never trimmed. The fact that
HandleWrap::OnClose is the libuv entry into the failing callback (frame
29) suggests the OOM fires when finalizing a libuv handle the worker
keeps spawning for git operations.

Suggested investigation

1. In Codex Framework's embedded Node bundle, locate the Worker

instantiated with { name: "git" } (or workerData indicating git).

1. Heap-snapshot that worker at 4 h, 8 h, 12 h of uptime. Watch the

retained-size growth of any cache keyed by repo path / commit SHA /
file path, plus any EventEmitter listener arrays.

1. Audit any setInterval / setTimeout chains in that worker that

retain closures over previous results.

1. Check whether the worker is unintentionally retaining results of every

git status / git log / git diff invocation in a Map / Array that
is never trimmed.

Privacy note for OpenAI engineers

Per-incident sanitized excerpts (exception / termination / faulting
thread frames / thread-count summary), the summary JSON, and the
sanitization script used are available on request. All PII (username,
home paths, UUIDs, IPs, MACs, deviceIdentifierForVendor,
crashReporterKey, boot session UUIDs, etc.) was stripped before
sharing; technical signature and backtraces are intact and sufficient
to debug.