›_ Codex Issues
Codex Issues / #30824

Codex Desktop 26.623.81905 crashes with EXC_BREAKPOINT/SIGTRAP in FSEvents uv__fsevents_close and leaves stale helpers

Open 💬 6 comments Opened Jul 1, 2026 by kerimala

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

Codex Desktop 26.623.81905 build 4598

Codex Framework / Chromium in crash report: 149.0.7827.197

What subscription do you have?

ChatGPT Pro

What platform is your computer?

  • macOS 26.5.1 (25F80)
  • Apple Silicon / ARM64
  • Hardware Model: Mac16,13
  • Memory module shown in report: LPDDR5, Micron
  • System Integrity Protection: enabled

What issue are you seeing?

Codex Desktop quit unexpectedly while running in the background. The macOS crash report points to an EXC_BREAKPOINT / SIGTRAP crash in a file-watcher / FSEvents path rather than a memory-pressure kill.

Crash summary from the macOS report:

Process:             Codex [9424]
Path:                /Applications/Codex.app/Contents/MacOS/Codex
Identifier:          com.openai.codex
Version:             26.623.81905 (4598)
Code Type:           ARM-64 (Native)
Role:                Background
Date/Time:           2026-07-01 09:06:24.0005 +0200
Launch Time:         2026-06-30 22:13:24.9933 +0200
OS Version:          macOS 26.5.1 (25F80)
Triggered by Thread: 51
Exception Type:      EXC_BREAKPOINT (SIGTRAP)
Exception Codes:     0x0000000000000001, 0x000000012c288898
Termination Reason:  Namespace SIGNAL, Code 5, Trace/BPT trap: 5
Terminating Process: exc handler [9424]

Crashing thread excerpt:

Thread 51 Crashed:
0   Codex Framework  0x12c288898 temporal_rs_PlainDateTime_hour + 5760080
1   Codex Framework  0x12c288898 temporal_rs_PlainDateTime_hour + 5760080
2   Codex Framework  0x12c2888b0 temporal_rs_PlainDateTime_hour + 5760104
3   Codex Framework  0x12c2888cc temporal_rs_PlainDateTime_hour + 5760132
4   Codex Framework  0x12c288f58 temporal_rs_PlainDateTime_hour + 5761808
5   Codex Framework  0x12c288df8 temporal_rs_PlainDateTime_hour + 5761456
6   Codex Framework  0x12482280c v8::internal::compiler::CompilationDependencies::RecordDependency(...) + 109820
7   Codex Framework  0x12463be30 v8::TryCatch::TryCatch(v8::Isolate*) + 34024
8   Codex Framework  0x12c28fc58 temporal_rs_PlainDateTime_hour + 5789712
9   FSEvents         0x19a01ba54 _FSEventStreamCreate + 900
10  FSEvents         0x19a016d4c FSEventStreamCreate + 76
11  Codex Framework  0x12fe2a008 uv__fsevents_close + 1472
12  CoreFoundation   __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
13  CoreFoundation   __CFRunLoopDoSource0 + 172
14  CoreFoundation   __CFRunLoopDoSources0 + 232
15  CoreFoundation   __CFRunLoopRun + 820
16  CoreFoundation   _CFRunLoopRunSpecificWithOptions + 532
17  CoreFoundation   CFRunLoopRun + 64
18  Codex Framework  0x12fe2a0e8 uv__fsevents_close + 1696
19  libsystem_pthread.dylib _pthread_start + 136
20  libsystem_pthread.dylib thread_start + 8

The crash report did not show EXC_RESOURCE, jetsam, memorystatus, or another explicit out-of-memory termination reason. A narrow unified-log check around the crash did not show a matching memory-pressure kill event.

After relaunch, stale orphaned helpers from the crashed session were still present with PPID 1 and the original June 30 launch time:

9426 browser_crashpad_handler
9428 browser_crashpad_handler
9442 bare-modifier-monitor --key DoubleCommand --immediate
9453 /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
9529 bare-modifier-monitor --key RightOption --trigger-on-release

They exited cleanly after sending normal TERM. The current relaunched Codex process tree remained running.

What steps can reproduce the bug?

I do not have a deterministic minimal reproduction yet.

Observed sequence:

  1. Launch Codex Desktop 26.623.81905 on macOS 26.5.1.
  2. Use Codex normally over a long-running session.
  3. Leave Codex running in the background.
  4. Codex unexpectedly quits after roughly 10h 53m of app uptime.
  5. macOS records EXC_BREAKPOINT / SIGTRAP on Thread 51, with top frames involving FSEventStreamCreate and uv__fsevents_close.
  6. After relaunch, stale helper processes from the crashed session remain orphaned under launchd until manually terminated.

What is the expected behavior?

Codex Desktop should not crash while closing or managing file-system watchers. If an FSEvents/libuv watcher operation fails during shutdown or cleanup, it should fail gracefully without terminating the main app process.

After a crash/restart, Codex should not leave stale app-server / helper processes from the old crashed session running under launchd.

Additional information

This appears related to the broader recent family of macOS Desktop EXC_BREAKPOINT / SIGTRAP crashes, but I did not find an exact existing issue for this newer build plus the FSEvents/libuv crash frame.

Related issues:

  • #30553 - Codex Desktop 26.623.61825 crashes with EXC_BREAKPOINT/SIGTRAP in CrBrowserMain on macOS 27.0
  • #27880 - Repeated macOS Codex Desktop 26.609 crashes: CrBrowserMain EXC_BREAKPOINT, Renderer SIGABRT, stale app-server helpers
  • #26869 - Codex Desktop app-server leaks child processes and writes excessive logs after crash/restart

I am not attaching the full raw crash report publicly because it contains local paths, timestamps, identifiers, and process command lines. I can provide a redacted excerpt or the full report privately if useful.

View original on GitHub ↗

6 Comments

griffin9899 · 19 days ago

Confirming this on Windows 11 (build 26200, 32 GB RAM), Codex Desktop 26.623.9142.0 — same helper-stack accumulation described here.
What I saw (matches this issue):
• Under the codex.exe app-server, ~21 node.exe ./mcp/server.mjs --stdio / server.bundle.mjs children (~52–54 MB each) plus accumulating node_repl.exe (computer-use), holding ~1.1 GB and climbing.
• The burst correlated exactly with 3 long computer-use sessions left open for hours (per-session ~510k / 579k / 732k tokens).
Two extra data points that may help the fix:

  1. Re-leak after surgical cleanup: killing just the node children while leaving the app-server alive is not sufficient — fresh mcp/server.mjs children (new PIDs) respawn under the same app-server within minutes. Only terminating the entire Codex app process tree stops it.
  2. Not user-MCP-config-related: my only configured MCP server is a remote HTTP endpoint (spawns no subprocess); the leaking mcp/server.mjs processes are app-internal, so this is Codex’s own child-process lifecycle, independent of user MCP config.

Repro: long/concurrent computer-use sessions left open → node_repl + internal mcp/server.mjs children accumulate and are not reaped on turn/session completion.
Requested: reap (or pool+reuse) internal MCP-server + node_repl children on turn/session completion, with a cap + idle reclamation, so long/multi-session use doesn’t leak host processes. Happy to provide a process-tree snapshot if useful.

andybergon · 19 days ago

Adding another matching data point from macOS.

Environment:

  • Codex Desktop: 26.623.70822 build 4559 for the first crash, then 26.623.81905 build 4598 for the second crash
  • macOS: 26.5.1 (25F80)
  • Hardware model: Mac17,8
  • Architecture: Apple Silicon / ARM64

Crash reports found locally:

2026-07-01 02:32:25 +0100
Codex 26.623.70822 (4559)
Incident: 33C9BFC3-C74B-48B7-8520-8AF4EB9BB37C
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: Trace/BPT trap: 5

2026-07-01 14:19:38 +0100
Codex 26.623.81905 (4598)
Incident: 0C8B5361-4C17-40E8-BCAA-4CB561369F5C
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: Trace/BPT trap: 5

Both crash reports have the same relevant faulting-thread shape as this issue:

temporal_rs_PlainDateTime_hour
v8::internal::compiler::CompilationDependencies::RecordDependency(...)
v8::TryCatch::TryCatch(v8::Isolate*)
_FSEventStreamCreate
FSEventStreamCreate
uv__fsevents_close
CFRunLoopRun
uv__fsevents_close
_pthread_start

The first crash is useful because it shows the same FSEvents/libuv EXC_BREAKPOINT / SIGTRAP signature one build earlier (26.623.70822 / 4559). The second crash matches this issue's build (26.623.81905 / 4598).

Adjacent app-log signal around the second crash: the Desktop log for the crashed PID repeatedly logged codex_chronicle lock contention before the crash window:

Starting local app-server sidecar ... command=/Applications/Codex.app/Contents/Resources/codex_chronicle
codex_chronicle starting
Waiting to acquire lock (owned by pid=48820)...

That lock-wait message repeated roughly every 10 seconds and was still repeating immediately before the 14:19:38 +0100 crash. After a later restart, a new Desktop log still showed the same Waiting to acquire lock (owned by pid=48820)... loop.

I am not attaching the full .ips or raw app logs publicly because they include local paths, process details, and identifiers. I can provide redacted excerpts or the raw files privately if helpful.

SoraTakai · 18 days ago

I'm getting this too, very often.
It is a critical bug.

It crashes when I'm not doing anything on it.

<img width="802" height="463" alt="Image" src="https://github.com/user-attachments/assets/8e1b4360-356c-4f58-8ac7-093df17e0b0e" />

gm-fire · 17 days ago

Adding another sanitized data point from a newer 26.623 build. This looks related to the same background-crash/stale-helper family, but with a few useful differences: stable macOS 15.3.1, app build 4674, and no pre-crash ERROR/WARN in Codex's own SQLite log window.

Environment:

  • Codex Desktop: 26.623.101652 / build 4674
  • Codex Framework / Chromium in the crash report: 149.0.7827.197
  • OS: macOS 15.3.1 (24D70)
  • Hardware model: Mac16,10
  • Architecture: Apple Silicon / ARM64
  • SIP: enabled

Crash summary from the macOS .ips report:

App: Codex 26.623.101652 (4674)
Process role: Background
Process launch time: 2026-07-02 13:24:16 +0800
Capture time: 2026-07-03 17:10:23 +0800
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: SIGNAL 5, Trace/BPT trap: 5
Faulting thread: 0
Thread name: CrBrowserMain
Queue: com.apple.main-thread

Top sanitized crashing frames:

0  temporal_rs_PlainDateTime_hour + 5760080
1  temporal_rs_PlainDateTime_hour + 5760080
2  temporal_rs_PlainDateTime_hour + 5760104
3  temporal_rs_PlainDateTime_hour + 5760132
4  temporal_rs_PlainDateTime_hour + 5761808
5  temporal_rs_PlainDateTime_hour + 5761456
6  v8::internal::compiler::CompilationDependencies::RecordDependency(...) + 110140
7  v8::TryCatch::TryCatch(v8::Isolate*) + 34024
8  v8::internal::ThreadIsolation::SplitJitPage(...) + 156568
9  temporal_rs_PlainDateTime_hour + 5789712
10 uv_handle_get_data + 157068
11 uv_handle_get_data + 155848
12 xml_ffi$cxxbridge1$194$saw_error + 12332
13 v8::Isolate::Dispose() + 487784
14 rust_png$cxxbridge1$194$Reader$output_color_type + 97284

VM triage lines in the same report:

VM - Fault was interrupted
VM - Waiting on busy page was interrupted
VM - Fault was interrupted
VM - Fault was interrupted
VM - Fault was interrupted

Post-crash process state:

  • Codex relaunched immediately: new main process around 17:10:52 +0800, new codex app-server --analytics-default-enabled child around 17:10:56 +0800.
  • One old codex app-server --analytics-default-enabled from the pre-crash session remained under launchd (PPID=1) after relaunch. I am omitting raw PIDs and local paths here.

Local log checks:

  • Crashpad only had a tiny browser sidecar (ptype=browser, osarch=arm64); no useful minidump payload was available locally.
  • Sentry local queue was empty; local Sentry scope showed release codex@26.623.101652.
  • A narrow macOS unified-log query around the crash did not return useful Codex events.
  • Codex logs_2.sqlite had no ERROR/WARN rows in the 10 minutes before the crash (17:00:23-17:10:23 +0800). It only showed normal codex_app_server::thread_state DEBUG rows in that pre-crash window.
  • After the crash time (17:10:23-17:20:23 +0800), logs_2.sqlite resumed with normal post-relaunch DEBUG/TRACE/INFO activity and one WARN from codex_core_plugins::manifest.

I intentionally did not attach the raw .ips or raw Codex log rows because they may contain local identifiers. I can provide a further-redacted excerpt if maintainers need a specific section.

SoraTakai · 16 days ago

What I don't understand is, how this critical bug gets literally zero response from the dev for so many days.

This is exactly why bug fixing should be automated by LLMs, like Anthropic does it.

kerimala · 9 days ago

Adding a new matching crash from a substantially newer Desktop build. The exact FSEvents/libuv signature is still present.

Environment:

  • ChatGPT/Codex Desktop: 26.707.41301 / build 5103
  • Codex Framework / Chromium: 150.0.7871.115
  • macOS: 26.5.2 (25F84)
  • Hardware: Mac16,13
  • Architecture: Apple Silicon / ARM64
  • App uptime before crash: about 19h 43m
  • Crash time: 2026-07-11 20:11:54 +0200

Crash summary:

Exception: EXC_BREAKPOINT (SIGTRAP)
Termination: SIGNAL 5, Trace/BPT trap: 5
Faulting thread: 52

_FSEventStreamCreate
FSEventStreamCreate
uv__fsevents_close
__CFRunLoopRun
CFRunLoopRun
uv__fsevents_close
_pthread_start

Local correlation:

  • The Desktop log had no ERROR/WARN immediately before the crash.
  • The final entries were normal periodic Statsig refreshes; the primary window was visible but unfocused.
  • Roughly five minutes earlier, the remote-control window context reconciled twice without a reported error.
  • Earlier in the session the app repeatedly started multiple git-repo-watcher instances across several repositories.

Inference: the crash report still points to a race/assertion while creating or closing a macOS FSEvents stream, likely in watcher lifecycle cleanup. The available logs do not identify one specific repository, file operation, prompt, or user action as the trigger.

Post-crash, the old process tree was not fully reaped. On 2026-07-12, the pre-crash codex app-server, codex-code-mode-host, two browser_crashpad_handler processes, and two bare-modifier-monitor processes were still alive under launchd with PPID 1, alongside the newly relaunched app tree.

The raw crash report and logs are not attached because they contain local paths and identifiers; sanitized excerpts can be provided if needed.