Codex Desktop App — Frequent Crash Report

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

26.623.101652

What subscription do you have?

no service

What platform is your computer?

_No response_

What issue are you seeing?

During normal use of the Codex desktop app, the application repeatedly crashes and quits unexpectedly. Within a short window (~30 minutes), it crashed twice, and both crashes share the exact same stack trace, indicating a consistently reproducible bug rather than a one-off event.
Each crash occurred after the app had only been running for a few to several minutes — suggesting the crash is triggered by a specific action (likely related to Git repository operations) rather than gradual resource accumulation over a long session.

__pthread_kill
pthread_kill
abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
v8::ToExternalPointerTag(...)
... (V8 internal GC / JIT related frames) ...
node::InternalCallbackScope::Close()
node::InternalMakeCallback(...)
node::AsyncWrap::MakeCallback(...)
node::worker::Worker::Run()
node::worker::Worker::SelfSize() const
_pthread_start
thread_start

Both crashes share the same termination info:

exception: EXC_CRASH / SIGABRT
termination: Abort trap: 6, byProc: Codex
asi: libsystem_c.dylib -> "abort() called"

Preliminary Root Cause Analysis

1. The crash is fundamentally a V8 heap allocation failure (OOM) leading to a self-triggered abort.node::OOMErrorHandler in the stack trace is Node.js/V8's standard handler invoked when a memory allocation fails, and it calls abort() to terminate the process. This is not the OS force-killing the process — it is Codex's own runtime detecting a memory problem and shutting itself down.
2. Both crashes are consistently triggered by the same Node Worker thread named "git", with nearly identical stack traces pointing to the same code path. This strongly suggests a reproducible bug in the application itself, rather than an issue specific to the user's environment. This worker likely handles repository-related operations (e.g., diff / status / log / file traversal).
3. This issue does not appear directly related to total physical system memory. This machine has 32 GB of RAM, a fairly generous configuration, and no memory pressure is observed with other applications running normally. The OOM is therefore more likely caused by one of the following:

○ The V8 heap (e.g., old space) has an internal size limit, and a specific operation triggers an unusually large memory allocation request that exceeds this limit — this can happen even when the system still has plenty of free physical RAM; or
○ The "git" worker has a memory leak or an unbounded, one-time data load when processing certain repository data (e.g., large files, oversized diffs, or traversing a large number of files), causing that worker's heap to grow continuously until it overflows.

Impact
● The app crashes repeatedly and unpredictably within short usage sessions, severely affecting normal usability.
● The crash is reproducible and appears strongly correlated with a specific repository or a specific Git-related operation.
● Because crashes happen suddenly, there is a risk of losing unsaved work.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f2c9f-04c0-7931-bcad-98a7cd2643b4

What is the expected behavior?

_No response_

Additional information

_No response_