Codex Desktop 26.623.81905 crashes with CrBrowserMain EXC_BREAKPOINT/SIGTRAP and app-server memory spike on macOS 27

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?

Not relevant to this local crash report.

What platform is your computer?

• macOS 27.0 (26A5368g)
• Apple Silicon / ARM64
• Hardware model in crash report: Mac17,8
• Physical memory: 64 GB
• SIP: enabled

What issue are you seeing?

Codex Desktop crashed while running in the background, then relaunched into an unhealthy state where a new codex app-server --analytics-default-enabled process consumed very high memory and CPU.

Crash summary from the macOS report:

Crash report: Codex-2026-07-02-224457.ips
Process: Codex [5758]
Path: /Applications/Codex.app/Contents/MacOS/Codex
Identifier: com.openai.codex
Version: 26.623.81905 (4598)
Code Type: ARM-64
Role: Background
Launch Time: 2026-07-02 10:03:41.6008 +0800
Capture Time: 2026-07-02 22:44:56.0901 +0800
OS Version: macOS 27.0 (26A5368g)
Faulting Thread: 0
Thread name: CrBrowserMain
Queue: com.apple.main-thread
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: SIGNAL 5, Trace/BPT trap: 5
Incident: 1ACB66E8-2AD2-4863-A6D7-6008A4AA77B7

The crash report also includes repeated VM triage lines:

VM Fault hit memory shortage
Fault was interrupted
VM Fault hit memory shortage
Fault was interrupted
VM Fault hit memory shortage

Top of the faulting thread is the familiar CrBrowserMain / V8 / Chromium native crash shape:

Thread 0 Crashed: CrBrowserMain
0  Codex Framework  ares_llist_replace_destructor + 2259972
1  Codex Framework  v8::ToExternalPointerTag(unsigned short) + 468
2  Codex Framework  v8::ToExternalPointerTag(unsigned short) + 352
3  Codex Framework  rust_png$cxxbridge1$194$Reader$get_iccp_chunk + 127636
4  Codex Framework  temporal_rs_PlainDate_calendar + 3572
...

After the crash/relaunch, Codex remained visibly resource-heavy. A live sample of the new app-server showed:

Process: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
PID: 47099
Launch Time: 2026-07-02 22:45:01.918 +0800
Physical footprint during sample: 10.4 GB
Physical footprint peak during sample: 23.1 GB

At approximately 2026-07-02 22:47:09-22:47:13 +0800, repeated ps samples showed the same new app-server around 119% to 254% CPU and RSS growing from roughly 13.6 GB to 14.2 GB.

A later sample at 2026-07-02 22:49:02 +0800 still showed:

PID    PPID   ELAPSED  STAT  %CPU   RSS
47099  47053  04:01    R     159.8  ~7.8 GB

There was also an old orphaned app-server from the pre-crash session still running under launchd:

PID   PPID  ELAPSED    COMMAND
5808  1     12:45:19   /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

The old app-server had previously peaked around 20.0 GB physical footprint in sample output, though it had fallen back to a smaller resident size by the time I inspected it.

In addition, the Chrome extension host for Codex was also memory-heavy during the same incident window:

Process: Codex for Chrome
Parent: Google Chrome
Physical footprint during sample: 6.6 GB
Physical footprint peak: 6.6 GB

The system was not globally out of memory at the exact later sample, but Codex-specific memory pressure was abnormal. memory_pressure still reported about 51% free memory at one later point, while the Codex app-server remained at multi-GB RSS and high CPU.

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 27.0 (26A5368g).
2. Use Codex normally in long-running desktop sessions with Browser / Chrome extension / Computer Use / MCP helpers available.
3. Leave Codex running for several hours.
4. Codex quits unexpectedly in the background after about 12h 41m uptime.
5. macOS records EXC_BREAKPOINT / SIGTRAP on Thread 0 CrBrowserMain with VM memory-shortage triage lines.
6. After relaunch, a new codex app-server --analytics-default-enabled grows to very high memory and CPU, while an old app-server from the crashed session remains orphaned under launchd.

What is the expected behavior?

Codex Desktop should not terminate the main app process with EXC_BREAKPOINT / SIGTRAP during a long-running session.

If Chromium/V8/native-module work hits memory pressure, Codex should fail gracefully, release memory, or surface a recoverable error rather than crashing.

After a crash/relaunch, Codex should cleanly retire stale app-server/helper processes from the previous session and should not immediately grow a fresh app-server to tens of GB peak physical footprint.

Actual behavior

• Main Codex process crashed with CrBrowserMain EXC_BREAKPOINT / SIGTRAP.
• Crash triage included repeated VM Fault hit memory shortage lines.
• After relaunch, a fresh app-server reached 23.1 GB peak physical footprint and sustained high CPU.
• An old app-server from the crashed session remained orphaned under launchd.
• The Codex Chrome extension host also showed high memory footprint during the same window.

Additional information

This appears related to the recent macOS Desktop crash/resource family, but this report adds a newer combination:

• latest observed app build here: 26.623.81905 build 4598
• macOS 27.0 (26A5368g)
• CrBrowserMain EXC_BREAKPOINT / SIGTRAP
• VM memory-shortage triage in the crash report
• post-relaunch app-server peak physical footprint of 23.1 GB
• stale orphaned app-server from the crashed session
• high-footprint Codex for Chrome extension host during the same incident

Possibly related issues:

• #30553 - Codex Desktop 26.623.61825 crashes with EXC_BREAKPOINT/SIGTRAP in CrBrowserMain on macOS 27.0
• #30824 - Codex Desktop 26.623.81905 crashes with EXC_BREAKPOINT/SIGTRAP in FSEvents uv__fsevents_close and leaves stale helpers
• #27880 - Repeated macOS Codex Desktop 26.609 crashes: CrBrowserMain EXC_BREAKPOINT, Renderer SIGABRT, stale app-server helpers
• #29510 - Codex app-server can grow to 30-40 GB when local rollout history is huge
• #26869 - Codex Desktop app-server leaks child processes and writes excessive logs after crash/restart

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