Git worker thread OOM crash (SIGABRT) when workspace contains nested git repos and large directory trees

What version of the Codex App are you using (From "About Codex" dialog)?

• 26.608.12217 (build 3722) — latest crash
• Also reproduced on 26.602.71036, 26.602.40724, 26.601.21317

What subscription do you have?

Pro plan

What platform is your computer?

• macOS 26.5.1 (25F80)
• Apple Silicon / arm64
• 128 GB RAM
• Bundle: com.openai.codex

What issue are you seeing?

Codex Desktop repeatedly crashes with SIGABRT on the git worker thread due to a V8 heap OOM. I have 12 crash reports spanning June 4–9, all with an identical stack signature. The crashes have been accelerating — 6 on June 9 alone, across two different app versions.

Unlike #26685 (where the git worker accidentally runs against the home directory), in my case the workspace root is correctly scoped to a specific project directory. However, the project has a structure that the git worker cannot handle:

• A root .git repository
• 5 nested subdirectories, each containing their own independent .git repo (full git directories, not worktree links)
• One subdirectory with 580+ sub-subdirectories (a content repository)
• A node_modules/ tree with 400+ package directories
• A worker-worktrees/ directory with 36 entries

The git worker thread appears to recursively process this entire tree without any memory bound, exhausting the V8 heap and calling abort().

Crash signature (identical across all 12 reports)

Exception:   EXC_CRASH (SIGABRT)
Termination: Abort trap: 6
Faulting thread: "git" (Node.js worker)

Thread (git):
  0: libsystem_kernel.dylib    __pthread_kill + 8
  1: libsystem_pthread.dylib   pthread_kill + 296
  2: libsystem_c.dylib         abort + 148
  3: Codex Framework            node::OOMErrorHandler(char const*, v8::OOMDetails const&) + 344
  4: Codex Framework            v8::ToExternalPointerTag(unsigned short) + 468
  5: Codex Framework            v8::ToExternalPointerTag(unsigned short) + 352
  6: Codex Framework            v8::internal::OptimizingCompileTaskExecutor::RunCompilationJob(...) + 445400
  ...
  30: Codex Framework           node::InternalCallbackScope::Close() + 716
  31: Codex Framework           node::InternalMakeCallback(...) + 464
  32: Codex Framework           node::AsyncWrap::MakeCallback(...) + 280
  33: Codex Framework           _register_external_reference_process_wrap(...) + 7600
  34: Codex Framework           uv__wait_children + 268
  35: Codex Framework           uv__io_poll + 1500
  36: Codex Framework           uv_run + 972
  37: Codex Framework           node::SpinEventLoopInternal(node::Environment*) + 480
  38: Codex Framework           node::worker::Worker::Run() + 4916

The uv__wait_children → process_wrap → MakeCallback → OOM pattern suggests the worker spawns a child git process, receives massive output back, and OOMs trying to allocate the result string in V8.

Steps to reproduce

1. Create a project directory containing:

• A root .git repository
• Multiple subdirectories that each contain their own independent .git directory (not worktree links)
• At least one subdirectory with hundreds of entries (e.g., a content repo or assets folder)
• A node_modules/ tree with hundreds of packages

1. Open this directory as the workspace root in Codex Desktop.
2. Use the app normally (start a thread, run any task).
3. The git worker thread will crash within minutes, taking down the entire app.

Expected behavior

1. The git worker thread should have a memory cap — if the V8 heap approaches its limit, it should abort the current git operation and degrade gracefully (e.g., disable git features for that workspace) rather than crashing the entire desktop app.
2. The git worker should not recursively descend into nested independent git repos. It should respect .git boundaries and only process the top-level repository.
3. Large git command output should be streamed or capped rather than buffered entirely into a V8 string allocation.

Additional information

• Related: #26685 (same OOM crash signature, but triggered by cwd being set to the home directory — a different root cause)
• Related: #26079 (same crash pattern reported by another user)
• Removing the home directory from config.toml trusted projects (as suggested in #26685) does not fix this — the crash persists when the workspace root is correctly scoped but the project tree is large.
• Session logs confirm the workspace root is correctly set to the project directory at crash time.
• All crash reports available in ~/Library/Logs/DiagnosticReports/Codex-2026-06-0*.ips