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

Open 💬 1 comment Opened Jun 11, 2026 by cocogoat-a

Summary

Codex Desktop is repeatedly crashing on macOS. The crash pattern is not a one-off: I have multiple main-process and renderer crash reports on 2026-06-11, plus repeated codex diagnostic reports over the previous week.

Please redirect if Codex Desktop crashes should be reported somewhere other than this repo.

Environment

  • App: Codex Desktop
  • Codex app version in crash reports: 26.608.12217 (build 3722)
  • Renderer/helper version in crash reports: 149.0.7827.54
  • CLI doctor: Codex Doctor v0.139.0, 16 ok, 0 fail, degraded
  • OS: macOS 26.5.1 (25F80)
  • Architecture: Apple Silicon / ARM64
  • Machine memory: 16 GB

Crash pattern

On 2026-06-11 local time, the main Codex process crashed 7 times and matching renderer helper crashes were generated around the same times.

Main Codex process:

  • 02:06:00 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5; ktriageinfo included VM Fault hit memory shortage
  • 02:14:10 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5; VM faults / busy page interrupted
  • 02:18:24 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5; VM faults including Didn't get back data for this file
  • 13:16:47 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5; VM fault / busy page symptoms
  • 15:16:40 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5; VM fault / busy page symptoms
  • 15:30:19 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5; VM fault / busy page symptoms
  • 15:44:15 — EXC_BREAKPOINT / SIGTRAP, Trace/BPT trap: 5

Renderer helper:

  • 02:05:57 — EXC_CRASH / SIGABRT, Abort trap: 6
  • 02:14:07 — EXC_CRASH / SIGABRT, Abort trap: 6
  • 02:18:21 — EXC_CRASH / SIGABRT, Abort trap: 6
  • 13:16:45 — EXC_CRASH / SIGABRT, Abort trap: 6
  • 15:16:37 — EXC_CRASH / SIGABRT, Abort trap: 6
  • 15:30:16 — EXC_CRASH / SIGABRT, Abort trap: 6
  • 15:44:13 — EXC_CRASH / SIGABRT, Abort trap: 6

There are also two Google Chrome crash reports in the same com.openai.codex resource coalition around 02:07 and 02:10, apparently from browser processes launched by Codex.

Other related diagnostics

In addition to the .ips crash reports above, macOS has generated many codex .diag reports over the last week (June 4-11). These are for /Applications/Codex.app/Contents/Resources/codex, often in the com.openai.codex resource coalition, with durations ranging from about 100 seconds to many hours. I am not pasting full diagnostics publicly because they may include local paths, but the repeated .diag reports line up with ongoing instability rather than a single isolated crash.

Suspicious Codex log events near the 02:14 and 02:18 crashes

Codex Desktop logs shortly before the crash cluster show:

  • repeated app-server/remote-control reconnect attempts ending with Remote control enrollment requires explicit authorization in settings
  • repeated sidecar lock waits: Waiting to acquire lock (owned by pid=...)
  • active in-app browser / browser sidebar lifecycle events
  • Chronicle screen capture / sparse memory frame writes
  • git/review-worker commands against generated build output

The clearest actionable trigger I found is a git/review-worker workload over a large generated .next tree:

  • one log line had argsCount=25915, requestKind=review-summary, failureReason=spawnFailed, with thousands of .next/... paths
  • another had argsCount=43733, also requestKind=review-summary, failureReason=spawnFailed
  • the renderer also logged worker_rpc_response_error with spawn E2BIG

This suggests Codex may be expanding too many generated/untracked paths into git/review commands instead of excluding build output or chunking the command.

Expected behavior

Codex should not repeatedly crash when a workspace contains large generated output. At minimum, the git/review worker should ignore known generated folders such as .next, chunk large path lists safely, or fail gracefully without taking down the Desktop app/main process.

Actual behavior

Codex Desktop repeatedly crashes. The crash reports point to main-process SIGTRAP with VM/page-fault symptoms and companion renderer SIGABRT crashes. The app can relaunch, but the crash pattern recurs.

Workarounds tried / current state

After a reboot, codex doctor --summary showed no hard failures:

  • 16 ok
  • 0 fail
  • degraded
  • warnings included many rollout files on disk and thread inventory issues
  • app-server was idle/not running in ephemeral mode

The likely local mitigation is to make sure generated directories such as .next and other QA/build artifacts are excluded from Codex/git review scope, but Codex should handle this defensively.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗