[app][macOS][26.727.51351] browser_crashpad_handler SIGTRAPs 2ms after launch, launchd respawns it, Crashpad/pending fills disk at ~17GB/day
Summary
browser_crashpad_handler shipped inside ChatGPT.app crashes 2.0 ms after launch with EXC_BREAKPOINT (SIGTRAP) inside CrashpadHandlerMain. Its parent is launchd, which immediately relaunches it, and each cycle writes a .dmp + _sidecar.json pair into Crashpad/pending. Nothing ever uploads or expires them.
The result is a self-feeding loop: the crash handler is the thing generating the crashes.
This filled a 228 GB boot disk from 34 GB free to literally 0 bytes in 48 hours, at which point the machine could not create new files at all.
This looks related to #25921, #30335 and #27136, but I have not seen the actual crash signature posted anywhere, so I am adding it here. Two differences from #27136 in particular: my handler runs from the installed /Applications bundle rather than a leftover /Volumes/Codex Installer/ mount, and my symptom is disk exhaustion rather than CPU.
Environment
| | |
|---|---|
| App | ChatGPT.app 26.727.51351 (build 6119) |
| Bundle ID | com.openai.codex |
| Codex Framework (Chromium) | 150.0.7871.182 |
| macOS | 15.7.3 (24G419) |
| Hardware | Mac16,10 — Apple M4, 16 GB |
| Installed | 2026-07-31 (via Sparkle auto-update) |
Sparkle reports auto-update enabled and a successful check on 2026-08-04 that offered nothing newer, so this is the current shipping build.
Crash signature
From ~/Library/Logs/DiagnosticReports/browser_crashpad_handler-*.ips:
exception : {"type": "EXC_BREAKPOINT", "signal": "SIGTRAP",
"codes": "0x0000000000000001, 0x0000000102ed75d8"}
procPath : /Applications/ChatGPT.app/Contents/Frameworks/
Codex Framework.framework/Versions/150.0.7871.182/Helpers/browser_crashpad_handler
parentProc : launchd (pid 1)
responsible : ChatGPT
coalition : com.openai.codex
procLaunch : 2026-08-02 00:31:08.2932
captureTime : 2026-08-02 00:31:08.3781
lifetime : 2.0 msFaulting thread — entirely inside the handler's own code:
browser_crashpad_handler +0x435d8 CrashpadHandlerMain
browser_crashpad_handler +0x42fe0 CrashpadHandlerMain
browser_crashpad_handler +0x9a730 CrashpadHandlerMain
browser_crashpad_handler +0x9a748 CrashpadHandlerMain
browser_crashpad_handler +0x393a0 CrashpadHandlerMain
browser_crashpad_handler +0x360c0 CrashpadHandlerMain
browser_crashpad_handler +0x776c CrashpadHandlerMain
dyld +0x6b98 startEXC_BREAKPOINT at 2 ms with no other module on the stack reads as a CHECK()/DCHECK() assertion failing during handler startup — i.e. it aborts before it ever reaches its normal service loop. The instruction at PC decodes to brk #0.
Measured growth rate
Counting files in Crashpad/pending at 20-second intervals on an otherwise idle machine:
t=0 files=34 size=2856 KB
t=20s files=74 size=6216 KB (+40 files, +3360 KB)
t=40s files=92 size=7728 KB (+18 files, +1512 KB)
t=60s files=92 size=7728 KB (+0, quiet)Peak 2 dumps/sec ≈ 0.6 GB/hour. It is bursty rather than continuous, but the long-run average matches: 34 GB consumed over 48 hours ≈ 0.7 GB/hour ≈ 17 GB/day. That is meaningfully worse than the "+5 GB/day" in #25921.
Snapshot at the point the disk hit zero: 127,137 files in Crashpad/pending, roughly 82 KB per dump.
Steps to reproduce
- Install ChatGPT.app 26.727.51351 on macOS 15.7.3 (Apple silicon).
- Use it normally for a day or two.
du -sh ~/Library/"Application Support"/Codex/Crashpad/pending
I have not isolated a specific user action that triggers a burst — it happens in the background while the app is merely running.
Expected
Crashpad should upload and delete dumps, or enforce a retention cap / TTL. It should never be possible for the crash reporter to consume the entire boot volume.
Separately: a handler that fails its startup assertion should not be relaunched indefinitely by launchd. Some backoff or a give-up threshold would turn a disk-filling outage into a silently degraded crash reporter, which is a much better failure mode.
Suggested fixes
- Bound the directory. A size cap or TTL on
Crashpad/pending(e.g. keep the last N dumps or 24 hours' worth) would prevent this entire class of failure regardless of the root cause. - Fix the startup assertion that kills
CrashpadHandlerMainat 2 ms. - Add relaunch backoff so a handler that dies immediately isn't respawned at 2 Hz forever.
- Delete on successful upload, and if no upload endpoint is configured, don't write dumps at all.
Item 1 alone would have prevented the outage.
Workaround for anyone hitting this
Note that once the disk is genuinely at 0 bytes, many tools stop working, and rm -rf <dir>/* fails with argument list too long at this file count. This works:
find ~/Library/Application\ Support/Codex/Crashpad/pending -type f -deleteIt frees space progressively, so the system becomes usable again partway through. I automated it with an hourly launchd agent since the directory refills.
5 Comments
I reproduced the same disk-filling Crashpad self-crash loop, but with a much larger accumulation. The foreground app remained usable and I did not observe any visible app or system crash.
Environment
26.730.616396234151.0.7922.71150.0.7871.12815.6.1 (24G90)arm64 / Mac14,2Accumulation
The affected directory was:
Before cleanup:
The files were paired minidumps and sidecars. Sample sizes:
Daily growth measured from file metadata:
Exact crash signature
Running
stringson multiple sampled minidumps consistently exposed this fatal assertion:The dump identified the crashing executable as:
and included:
This confirms that the crash reporter itself was failing and producing reports about its own failure, rather than the foreground app visibly crashing.
Update/relaunch timing
The app bundle had already updated, but an old-framework dump was still created at
2026-08-06 22:32:15. A clean app relaunch at22:37started Framework151.0.7922.71. The pending directory's final modification time was22:36:46, and it did not grow during a post-relaunch observation window.This suggests the loop may involve an old Crashpad helper surviving an in-place update until a full relaunch, in addition to the missing retention/size cap.
I did not attach raw minidumps because they may contain private memory or local paths. The 531k files were removed with
find ... -delete, which freed space progressively. A hard size/count cap or TTL would have prevented this from consuming most of the boot disk.Same issue on macOS 15.7.4, Apple M3 Max.
chatGPT 26.730.61309
I can confirm the same Crashpad self-crash loop on macOS arm64, with one additional trigger/timeline data point.
I am not attaching raw minidumps because they may contain local paths or private process data. I can provide a redacted sample and a Codex /feedback session ID privately if useful.
Reproduced on a newer ChatGPT desktop build after updating and restarting the app.
Environment
26.820.60940(bundle build7119)151.0.7922.17015.5 (24F74)Mac14,7com.openai.codexReproduction after update
The previous
Crashpad/pendingbacklog had been cleaned before retesting. With the updated app running:That is 12 new minidumps in 13 seconds, still approximately one crash per second. Each observed
.dmpis about 160 KB and has a 24-byte_sidecar.json, projecting to roughly 14 GB/day. Before cleanup this had consumed more than 150 GB and left the macOS data volume 99% full.Crash signature
The Apple diagnostic report identifies the bundled helper itself:
The faulting thread begins inside
logging$internal$cxxbridge1$194$init_rust_logging, followed byCrashpadHandlerMainframes. The main ChatGPT UI remains usable whilelaunchdrepeatedly restarts the crash handler andCrashpad/pendinggrows in the background.Updating to
26.820.60940therefore does not resolve the crash loop. A sanitized Apple.ipsdiagnostic is attached; crash-report UUIDs, local user ID, boot-session UUID, and regional eligibility metadata were redacted while retaining the stack trace and binary paths.<details>
<summary>Sanitized Apple .ips diagnostic</summary>
</details>
+1