Codex Desktop repeatedly crashes with EXC_BREAKPOINT/SIGTRAP and VM fault symptoms when git/review worker scans large generated output

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

• #27570
• #27382
• #26357

Powered by Codex Action

Adding a current-build, simpler reproduction and a fresh crash-frequency data point from macOS. Local paths and project identifiers are intentionally omitted.

Environment

• Codex Desktop / bundle com.openai.codex (the executable and crash-report process name are ChatGPT)
• Current app: 26.715.72359 (build 5718)
• Also reproduced across 26.707.72221 (5307), 26.715.31251 (5538), 26.715.52143 (5591), 26.715.61943 (5628), and 26.715.72028 (5706)
• Codex Framework: 150.0.7871.124 on current builds
• macOS 26.5.1 (25F80), Apple Silicon / arm64, 48 GB RAM
• Apple Git 2.50.1

Frequency and crash signature

The local Crashpad database contains 60 browser-process crash sidecars from June 17 through July 22, including 33 since July 16. For those 33 events, the median interval is 3.45 hours (mean 4.35 hours). macOS retained seven full .ips reports from July 16-22, including two on July 22.

All seven retained reports are main-process crashes with:

• EXC_BREAKPOINT / SIGTRAP
• termination Trace/BPT trap: 5
• the same atPC instruction byte stream
• six faulting threads named git; one named Chrome_IOThread, but at the same trap site/instruction stream

The two July 22 sessions crashed after 3h13m and 2h35m of uptime. This is a deliberate trap/assertion path, not a macOS jetsam kill.

The latest git thread stack reaches V8 serialization and Node worker messaging:

v8::ValueSerializer::WriteValue(...)
node::worker::Message::Serialize(...)
node::worker::MessagePort::PostMessage(...)

Other reports in the same family reach UTF-8 decoding and node::worker::MessagePort::OnMessage. Some upper symbols are nearest-export artifacts in the stripped framework, so the exact private function name at the trap site is not reliable; the identical PC bytes and worker/message serialization frames are reliable.

Simple trigger: one very large untracked file

The strongest reproducible trigger is a single untracked, non-ignored generated gzip file of exactly 4,015,221,569 bytes inside an otherwise normal Git workspace.

While the workspace was open, Desktop's review-summary worker repeatedly ran this command shape against that one file:

git -c core.hooksPath=/dev/null -c core.fsmonitor= hash-object -- <large-untracked-file>

Each invocation ran for roughly 5.5-7.2 seconds, was logged as aborted=true, failureReason=aborted, success=false, then retried about every 15 seconds without meaningful backoff.

In the 10 minutes before the latest crash, there were 39 failed/aborted hash-object attempts. The last completed at 09:42:34Z; the app trapped at 09:42:42Z, eight seconds later, on the git worker.

The preceding July 22 crash had the same loop (39 hash-object aborts in the final 10 minutes), followed by three aborted git diff jobs. Each diff buffered 3,866,624 stdout bytes; the app trapped seven seconds after the last one.

Six of the seven retained crashes had active review-summary Git failure/abort activity in the preceding ten minutes. Examples:

| Crash | hash-object failures | diff failures | Window |
|---|---:|---:|---|
| Jul 18 | 49 | 95 | final 10 min |
| Jul 20 | 0 | 2 | final 10 min |
| Jul 21 (first) | 5 | 14 | final 10 min |
| Jul 21 (second) | 18 | 180 | final 10 min |
| Jul 22 (first) | 39 | 3 | final 10 min |
| Jul 22 (second) | 39 | 0 | final 10 min |

The remaining older crash had only a benign failed branch lookup in that window, so the Git loop explains most but not necessarily every occurrence.

Process cleanup leak / compounding condition

After repeated crashes, a live process inventory contained 121 executables from old Codex/ChatGPT app sessions, 101 reparented to launchd (PPID 1), consuming about 4.3 GiB RSS in aggregate. Most stale processes were paired Crashpad handlers and bare-modifier-monitor helpers; two old codex app-server processes also remained detached. Some surviving helpers came from app/framework versions no longer current.

This is not the direct SIGTRAP site, but it is a persistent cleanup defect and likely compounds long-running instability.

Other environmental observation

The data volume was 99% full with about 11 GiB available. That may worsen repeated hashing/temp-I/O behavior, but system memory pressure was healthy (85% free at inspection), the machine has 48 GB RAM, and every retained termination is SIGTRAP rather than an OS resource kill.

Expected behavior / suggested guards

• Skip or explicitly cap review/diff processing for individual untracked files above a safe size threshold.
• Do not immediately and indefinitely retry a deterministic hash-object abort; deduplicate work and apply backoff/circuit breaking.
• Propagate cancellation through the full Git operation and clear the queued item.
• Bound/stream worker message payloads rather than serializing large Git results into V8 values.
• A Git worker failure must degrade Git/review features without trapping the entire desktop process.
• Reap Crashpad, modifier-monitor, app-server, and other helpers after app exit/crash.

Raw .ips and desktop logs are not attached because they contain local paths and workspace identifiers, but the seven crash reports can be provided privately if an OpenAI maintainer requests them.

Corroborating this on a newer Codex Desktop build, with a very large monorepo but a tiny current Git status.

Environment

• Codex Desktop: 26.721.41059 (build 5848)
• Codex Framework: 150.0.7871.128
• macOS: 26.5.1 (25F80)
• Architecture: Apple Silicon / ARM64
• Physical memory: 48 GB

Repeated crash signature

I found seven browser-process .ips reports between 2026-07-26 05:44 and 2026-07-27 18:37. Five were triggered on a thread named git with:

• EXC_BREAKPOINT
• SIGTRAP
• Trace/BPT trap: 5

A sixth report triggered on ThreadPoolForegroundWorker in the same V8 serialization class. The recurring git thread stack includes:

_malloc_zone_realloc
_realloc
v8::ValueSerializer::WriteValue   (repeated)
node::worker::Message::Serialize
node::worker::MessagePort::PostMessage
node::worker::MessagePort::OnMessage
uv_run
node::worker::Worker::Run

The foreground-worker variant includes v8::ValueSerializer::WriteRawBytes.

Workspace scale

• Workspace: 463 GB, approximately 816,165 files
• Generated output/: 156 GB, approximately 274,377 files
• .git: 20 GB; packfiles total 14.12 GiB
• Tracked files: 31,343
• Linked worktrees: 8
• Current git status --porcelain=v2 -z output: only 190 bytes (one modified file)

This supports the theory that a background Git/workspace worker is producing or serializing an unbounded result even when the actual status result is tiny. Large ignored/generated trees and multiple worktrees appear to amplify the bug.

There was no macOS memory-pressure/Jetsam event around the inspected crash, and the data volume still had 48 GB free. I am not attaching the raw .ips files publicly because they include local paths and device identifiers, but I can provide sanitized stack excerpts if maintainers need more detail.

Adding another current-build reproduction from macOS. This is the third time Codex has completely frozen/crashed and exited for this user.

Environment

• App/bundle: ChatGPT desktop app / com.openai.codex
• App version: 26.803.41515 (build 6321)
• Architecture: ARM64 (native)
• Hardware: Mac16,1
• macOS: 26.5.2 (25F84)
• Crash time: 2026-08-10 16:24:45 -0300
• App launch time: 2026-08-10 16:22:18 -0300
• Incident Identifier: C70FAABA-0DB3-4A88-8EDB-F81DF1FA3806

Crash signature

• Triggered by thread: 20 Chrome_IOThread
• Exception: EXC_BREAKPOINT (SIGTRAP)
• Termination: Namespace SIGNAL, Code 5, Trace/BPT trap: 5
• Faulting stack is inside Codex Framework and includes Node/V8-related frames.

Top of the crashed thread:

Thread 20 Crashed:: Chrome_IOThread
0   Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16449660
1   Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16449684
2   Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16449712
3   Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16462588
4   Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16450928
5   Codex Framework  node::MemoryRetainer::IsRootNode() const + 24356
6   Codex Framework  node::MemoryRetainer::IsRootNode() const + 19520
7   Codex Framework  v8impl::Reference::InvokeFinalizerFromGC() + 983244
8   Codex Framework  node::CustomBufferJSListener::OnStreamAlloc(unsigned long) + 101756
9   Codex Framework  node::CustomBufferJSListener::OnStreamAlloc(unsigned long) + 96792

This looks very similar to the crash family already documented here: SIGTRAP in the desktop app with a Chrome_IOThread / Node/V8 path. I don't have a reliable minimal trigger yet; the important new data point is that the problem is still occurring on the much newer 26.803.41515 build and has happened three times for this user.

A full macOS crash report is available if a maintainer wants the complete stack / diagnostics.

Adding another current-build reproduction of the Chrome_IOThread / SIGTRAP crash family.

Environment

• Codex Desktop bundle: com.openai.codex (crash-report process name: ChatGPT)
• App version: 26.814.41407 (build 6720)
• macOS: 26.4.1 (25E253)
• Hardware: Mac15,10, Apple M3 Max, 96 GB RAM
• Architecture: ARM64 native
• Crash time: 2026-08-22 19:39:06 -0700
• App launch time: 2026-08-16 18:50:31 -0700

Crash signature

• Triggered thread: 20 Chrome_IOThread
• Exception: EXC_BREAKPOINT (SIGTRAP)
• Termination: Namespace SIGNAL, Code 5, Trace/BPT trap: 5
• Faulting PC: 0x124c94e34

Top of the crashed thread:

Thread 20 Crashed:: Chrome_IOThread
0  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16383116
1  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16383140
2  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16383168
3  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16396144
4  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16384376
5  Codex Framework  node::MemoryRetainer::IsRootNode() const + 14708
6  Codex Framework  node::MemoryRetainer::IsRootNode() const + 9876
7  Codex Framework  v8impl::Reference::InvokeFinalizerFromGC() + 990872

The instruction stream at the faulting PC begins with ARM64 BRK #0; HLT #0; BRK #1, consistent with a deliberate fatal trap/assertion rather than an ordinary invalid-memory exception.

I do not have a reliable reproduction trigger. Unlike the original report, this crash is not currently tied to a large generated tree, large untracked file, or a known Git-worker loop. The .ips also does not contain an explicit memory-shortage, jetsam, or ktriageinfo marker, so I cannot establish memory exhaustion as the cause.

This shows that the same Chrome_IOThread crash signature is still occurring on build 26.814.41407. A complete crash report is available privately if an OpenAI maintainer needs it.

Adding a fresh reproduction on a newer Codex Desktop build. All local paths, account details, device identifiers, workspace names, conversation IDs, prompts, and raw diagnostic files are intentionally omitted.

Environment

• Codex Desktop bundle: com.openai.codex (crash-report process name: ChatGPT)
• App version: 26.818.41509 (build 6962)
• Codex Framework: 151.0.7922.170
• macOS: 26.5 (25F71)
• Platform: Apple Silicon / ARM64, running natively
• Previous app-process uptime before the crash: approximately 29 hours 39 minutes

Crash signature

• Crashpad capture kind: crash, process type: browser
• Triggered thread: 20 Chrome_IOThread
• Exception: EXC_BREAKPOINT (SIGTRAP)
• Termination: Namespace SIGNAL, code 5, Trace/BPT trap: 5
• The terminating process was the app itself; this was not an external kill or a clean quit.

Top of the faulting thread:

Thread 20 Crashed:: Chrome_IOThread
0  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16386020
1  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16386044
2  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16386072
3  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16398904
4  Codex Framework  node::inspector::protocol::BinaryValue::asBinary(...) + 16387292
5  Codex Framework  node::MemoryRetainer::IsRootNode() const + 15316
6  Codex Framework  node::MemoryRetainer::IsRootNode() const + 10484
7  Codex Framework  ChromeMain + 10228

The instruction stream begins with the same ARM64 fatal-trap sequence described in the earlier current-build reproduction. The nearest exported symbols in this stripped framework are not assumed to identify the exact private function.

Failure boundary

The separately running Codex app-server survived. Within roughly 0.1 seconds of crash capture it started reporting that messages were being dropped for the disconnected desktop connection. This isolates the termination to the desktop/browser shell rather than the app-server backend.

The app was manually reopened on the same app and framework build. It resumed successfully, and no second crash report appeared during the initial observation period. This was not an update-time restart.

Activity immediately before the crash

There is no reliable minimal reproduction yet. The following bounded observations may help identify the assertion path:

• Five distinct Codex threads emitted events during the final 48 seconds.
• Multiple assistant-stream deltas and lifecycle events were being delivered concurrently at the disconnect boundary.
• Two sampling streams had recently retried after WebSocket connections closed normally.
• Roughly 2 minutes 20 seconds before the crash, Desktop logged a thread-catalog sync timeout after an app-server request had taken about 267 seconds.
• The final persisted Desktop UI log event was an incoming reasoning-summary delta approximately 30 seconds before crash capture.
• There was no retained companion renderer .ips report for this occurrence.

This occurrence was not tied to a known large generated tree, giant untracked file, Git hash-object retry loop, or an observed review-worker failure. It therefore corroborates the later reports that the Chrome_IOThread trap family can occur outside the original Git-heavy reproduction.

What the diagnostics rule out

• No EXC_RESOURCE, jetsam, memory-shortage, or VM-fault marker appears in the retained crash report.
• The termination was not SIGKILL, SIGSEGV, or an external process termination.
• The app reopened on the identical build, ruling out an in-progress application update as the immediate cause.
• No third-party executable appears on the faulting stack. Local integrations may have contributed background load, but the available evidence does not attribute the trap to a specific integration.

Expected behavior

Concurrent streams, reconnects, or a stalled app-server request should degrade or reconnect cleanly. They should not trigger a fatal assertion in the Desktop browser process. A failed desktop connection should also avoid leaving prior helper processes detached.

Requested investigation

• Symbolicate the fatal PC for framework 151.0.7922.170 and inspect the underlying Chrome_IOThread CHECK/assertion.
• Check whether concurrent app-server event delivery, connection teardown, or network/IPC cancellation can reach that assertion.
• Ensure the desktop shell bounds or drains queued stream events during disconnect and degrades without terminating the process.

The raw .ips report and Desktop logs are intentionally not attached because they contain local paths and machine identifiers. A privately shared, sanitized diagnostic can be prepared if a maintainer needs additional fields.