Codex App crashes when internal Git worker runs out of memory on a large staged change set

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

26.715.31925 (build 5551)

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The Codex App hard-crashed twice while the same unusually large local Git repository was open. Both macOS crash reports have the identical signature.

This was a full application self-abort, not a renderer crash, network disconnect, solver failure, or macOS memory-pressure termination.

In both reports:

• exception: EXC_CRASH / SIGABRT
• termination: SIGNAL, Abort trap: 6
• faulting thread: 54, named "git"
• termination.byProc: ChatGPT
• relevant stack:

__pthread_kill
pthread_kill
abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
v8::ToExternalPointerTag(unsigned short)
v8::ExternalMemoryAccounter::Update(v8::Isolate*, long long)
cppgc::internal::MakeGarbageCollectedTraitInternal::Allocate(...)
node::worker::MessagePort::OnMessage(...)
uv_run
node::worker::Worker::Run()

The internal Git Node/V8 worker therefore entered an out-of-memory path while accounting for or allocating external memory. Node then called abort(), terminating the entire Codex App.

The repository state measured during the post-crash investigation was:

• approximately 2.8 GB and 82,398 files
• 3,582 tracked status entries
• 3,579 staged paths
• 3,890 untracked files
• 7,472 total status entries
• staged diff: 3,579 files, 195,793 additions and 1,132,253 deletions
• 2,681 staged deletions, including approximately 2,675 files from a previously tracked .venv

Git itself reported that exhaustive rename detection was skipped because there were too many files.

The crash reports do not symbolicate the intervening JavaScript/JIT frames, so they cannot establish whether the unbounded operation is specifically status enumeration, diff generation, rename detection, or another Git integration task.

What steps can reproduce the bug?

This is the best available high-fidelity reproduction. It has reproduced naturally twice, but it is not yet a minimal deterministic test case.

1. On a 16 GB Apple-silicon Mac, install Codex App 26.715.31925 build 5551.
2. Open a local Git repository of approximately 2.8 GB containing about 82,000 files.
3. Stage approximately 3,579 paths, including:

• about 2,681 deletions;
• about 2,675 deleted files from a tracked Python .venv;
• 775 additions;
• 60 renames;
• approximately 1.13 million deleted lines and 196,000 added lines.

1. Add approximately 3,890 untracked files, producing about 7,472 Git status entries in total.
2. Open this repository as the active local project in Codex App and leave the changes uncommitted.
3. Use the repository normally, including Git status refreshes and staged/source-control diff views.
4. Leave the project open for repeated background Git refreshes.

Observed result: the complete Codex App process eventually aborts. The generated macOS .ips report shows SIGABRT from node::OOMErrorHandler on the internal thread named "git".

The two observed crashes occurred after approximately 3 hours 21 minutes and 4 hours 13 minutes of process uptime.

Session ID: not applicable; this is a process-level Git integration crash and occurred across normal app usage.

What is the expected behavior?

Git integration should remain memory-bounded, even for unusually large repositories or change sets.

If a status or diff exceeds a safe threshold, Codex should truncate or paginate the result, skip expensive rename detection, or show a recoverable error.

An out-of-memory condition or failure in the auxiliary Git worker must not terminate the entire Codex App.

Additional information

Frequency:

• Two full-process crashes recorded in macOS Diagnostic Reports
• Crashes were separated by 5 hours 26 minutes 59.5 seconds
• 2/2 reports had the identical Git-worker OOM signature

Environment:

• MacBook Air Mac17,3
• Apple M5
• 16 GB RAM
• arm64
• macOS 26.5.2 build 25F84

Crash 1:

• Capture time: 2026-07-19 18:56:36.1683 +03:00
• Incident: 86121E77-2178-4CBC-BB60-1F925C6D57DA
• PID: 29646

Crash 2:

• Capture time: 2026-07-20 00:23:35.7003 +03:00
• Incident: D149DD22-ADB2-44B1-8383-64F3F54CD0A9
• PID: 77481

I can provide both original macOS .ips crash reports.