›_ Codex Issues
Codex Issues / #30928

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

Open 💬 4 comments Opened Jul 2, 2026 by NightGlowww
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30553

Powered by Codex Action

NightGlowww · 1 month ago

Thanks for the duplicate check. I reviewed #30553 and agree it is closely related, but I do not think this is an exact duplicate yet.

The overlap is:

  • macOS 27.0
  • CrBrowserMain
  • EXC_BREAKPOINT / SIGTRAP
  • Codex Framework / Chromium 149.0.7827.197

The additional evidence in this report is different/newer:

  • app build is 26.623.81905 / build 4598, while #30553 was 26.623.61825 / build 4548
  • the crash report includes repeated VM Fault hit memory shortage triage lines
  • after relaunch, the fresh codex app-server --analytics-default-enabled reached 23.1 GB peak physical footprint and sustained high CPU
  • an older app-server from the crashed session remained orphaned under launchd
  • the Codex for Chrome extension host also showed a 6.6 GB physical footprint in the same incident window

So #30553 is probably in the same crash family, but this issue adds a newer build plus post-crash app-server/extension memory behavior. If maintainers prefer consolidating these, I am fine with closing this after the newer memory/process evidence is copied into the canonical issue.

NightGlowww · 1 month ago

Additional crash from the same session family, shortly after the original report.

A second macOS crash report was generated:

Crash report: Codex-2026-07-02-233447.ips
Incident: 1181E16A-7E9A-46C5-BC60-BC6029C16153
App: Codex 26.623.81905 (4598)
OS: macOS 27.0 (26A5368g)
Process: Codex [47053]
Launch Time: 2026-07-02 22:45:01.2302 +0800
Capture Time: 2026-07-02 23:34:45.3978 +0800
Faulting thread: 0
Thread name: CrBrowserMain
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: SIGNAL 5, Trace/BPT trap: 5

This is the main Codex process that relaunched after the earlier 22:44 crash. It crashed again about 49 minutes later.

The top crashing frames are the same shape as the earlier report:

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
...

The VM triage lines are slightly different from the first crash, but still point at VM fault/page pressure rather than a clean handled failure:

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

After this second crash, Codex relaunched again. The new app-server immediately reproduced the high-memory pattern:

New main process: 71392
New app-server: 71426
App-server launch time: 2026-07-02 23:34:48.471 +0800
Sample time: 2026-07-02 23:36:07.902 +0800
Physical footprint during sample: 11.7 GB
Physical footprint peak: 23.1 GB

A live process snapshot at about 2026-07-02 23:36:xx +0800 showed:

PID    PPID   ELAPSED  STAT  %CPU   RSS
71426  71392  01:19    R     190.4  ~12.0 GB

The original orphaned app-server from the pre-crash session was still present:

PID   PPID  ELAPSED   COMMAND
5808  1     13:32:24  /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

So the pattern is now reproducible across two consecutive Codex main-process crashes in the same evening:

  1. 22:44:56 crash: pid 5758, CrBrowserMain, EXC_BREAKPOINT / SIGTRAP, VM memory-shortage triage, followed by app-server peak 23.1 GB.
  2. 23:34:45 crash: pid 47053, same CrBrowserMain / EXC_BREAKPOINT / SIGTRAP top frames, followed by a newly relaunched app-server again peaking at 23.1 GB within about 80 seconds.

I still have not posted raw .ips contents publicly because they may contain local identifiers and command lines, but I can provide a redacted excerpt or full report privately if maintainers need it.

Jackstonebreaker · 18 days ago

Confirming this on a different build and a different macOS version, with the same faulting signature. Adding measurements in case they help narrow it down.
A third occurrence produced no .ips at all: the app froze, the process tree survived (same PIDs, uptime continuous), and the UI recovered on its own. So the failure mode has at least two shapes — hard V8 abort and soft hang.

app-server footprint

Measured with /usr/bin/sample rather than ps rss, since RSS on macOS over-reports shared and compressed pages here by roughly an order of magnitude.

codex app-server   Physical footprint:        1.6 GB
                   Physical footprint (peak): 20.6 GB
main ChatGPT proc  Physical footprint:        2.4 GB
                   Physical footprint (peak):  4.2 GB

The 20.6 GB peak was reached twice, on two different app-server PIDs, in both cases within roughly 40 minutes of launch. Current footprint drops back afterwards, so this reads as a spike-and-release pattern rather than monotonic growth.

One MCP server set per open thread

This may be a separate issue, but it is the largest amplifier I could measure, so including it here.

With 10 locally-spawned MCP servers configured in ~/.codex/config.toml and 6 threads open, the app-server had 68 direct child processes totalling 10.1 GB, with a clean 6× pattern:

7 x sequential-thinking
6 x context7
6 x meta-ads
6 x tailwindcss
6 x shadcn-ui
6 x server-filesystem   (project dir 1)
6 x server-filesystem   (project dir 2)
6 x server-filesystem   (project dir 3)
6 x server-filesystem   (project dir 4)
6 x node_repl

Each npx-launched server costs an npm exec wrapper plus a node child. Nothing appears to be shared across threads, and nothing is reclaimed while the app stays open.

Reducing the config from 10 local servers to 5 — merging four server-filesystem declarations into one multi-root declaration, and disabling three optional servers — changed this to:

before:  68 child processes, 10.1 GB,  app-server peak 20.6 GB
after:    5 child processes,  0.8 GB,  app-server peak  205 MB

Same workload, same machine, restart in between. This does not fix the underlying spike (see below), but it moves the ceiling a long way.

logs_2.sqlite

Matches what is reported in #21134, at a larger scale:

file size          4,005,728,256 bytes  (3.73 GiB)
WAL                   13,435,352 bytes
retained rows            505,398
max AUTOINCREMENT  1,096,361,184        <- rows written over the DB lifetime
freelist             744,682 pages @ 4096 = ~2.84 GiB reclaimable in-file

Roughly 76% of the file is freelist. Over one billion rows have been written and pruned, while only ~505k are retained.

Last hour by level:

TRACE  2879
DEBUG  1340
INFO   1012
WARN    553
ERROR    14

Top targets, last hour:

codex_app_server::outgoing_message   1449
codex_api::sse::responses             771
codex_core::stream_events_utils       564
codex_core_skills::loader             354
codex_config::loader::macos           294
feedback_tags                         274

codex_core_skills::loader emitted 182 warnings on a single skills/list request, all of the same two shapes:

load_plugins_from_layer_stack: ignoring interface.icon_large: icon path with '..' must resolve under plugin assets/
load_plugins_from_layer_stack: ignoring interface.icon_small: icon path with '..' must resolve under plugin assets/

plus codex_core_plugins::manifest:

ignoring interface.defaultPrompt: maximum of 3 prompts is supported

These are cosmetic in themselves, but they are re-emitted in full on every skills/list, which the renderer requests repeatedly.

For scale, the whole ~/.codex directory is 70 GB (27 GB worktrees, 19 GB visualizations, 12 GB archived_sessions, 3.9 GB sessions, 3.7 GB logs_2.sqlite).

Requests

  1. Bound logs_2.sqlite by bytes, not only by row count, and VACUUM or use auto_vacuum so the freelist does not hold ~2.8 GiB.
  2. Deduplicate or rate-limit the skills/plugins loader warnings — they should not be re-emitted per skills/list.
  3. Share MCP server instances across threads, or at least reap them when a thread closes.
  4. Surface app-server footprint in the app so users can see the spike before the crash.

Happy to provide further sanitized diagnostics if maintainers specify which fields are useful. Raw rollouts and log bodies are withheld as they contain client data.