Codex Desktop Crashpad Bug (Issue #25921): Unbounded Pending Dumps Filling macOS Disks
OpenAI's Codex Desktop app for macOS continuously generates Crashpad crash dumps into a local pending directory with no size cap, no time-to-live, and no pruning, so the folder grows without bound while the app itself remains usable. GitHub issue openai/codex#25921, opened by user Jolg42 on June 2, 2026, documents the original report of 4.9 GB and 54,504 files in a single day; follow-up comments over the next four months report 59 GB, 61 GB, 100 GB, 137 GB, 174 GB, and a combined ~323 GB across two Crashpad paths on one machine.
The issue is labeled app, bug, and performance and remained open at the time of the source scrape. The core defect has two separable parts: a Crashpad handler that crashes and respawns in a loop on affected macOS versions, and a total absence of retention limits on the directory those crashes write into.
What the bug actually is
Codex Desktop ships a Chromium/Electron browser_crashpad_handler helper. On affected machines that handler fails during startup and writes a minidump of itself, then gets relaunched and fails the identical check again. Each iteration produces a paired .dmp file and a _sidecar.json metadata file in the Crashpad pending queue.
The user-visible symptom is not a crash of the Codex app. The app stays functional — users can interact with it and inspect the filesystem from the same session — while disk usage climbs silently in the background. Nothing in the app surfaces a warning.
Reported disk usage across versions
The scale of the growth varied widely by machine and by how long the loop ran undetected.
| Reporter | Date | App version | Reported size | Files |
|---|---|---|---|---|
| Jolg42 (author) | Jun 2, 2026 | 26.527.60818 | 4.9 GB in one day | 54,504 |
| mxggle | Jun 7, 2026 | — | 59 GB | hit the 65,535 file limit |
| dionylon | Jun 9, 2026 | 26.602.71036 | 58.89 GiB | 738,864 |
| guojianlan | Jun 18, 2026 | 26.611.62324 | 137.32 GiB | 1,786,086 |
| libairi | Jul 21, 2026 | 26.715.70719 | ~33.4 GiB | — |
| austinhutchison | Aug 15, 2026 | 26.803.61601 | ~100 GB | ~1 million |
| dewalt-1 | Sep 2, 2026 | 26.818.41509 | 174.6 GB | ~1.08M dumps, >2M files |
| ashtonsix | Oct 5, 2026 | 26.930.21537 | 114.22 GB | 1,212,428 |
| ahmedkhan25 | Oct 17, 2026 | 26.1007.71326 | ~323 GB across two paths | ~4.04 million |
The original report measured 27,252 .dmp files and 27,252 _sidecar.json files — an exact 1:1 pairing — totaling 4.9 GB. After the author deleted the contents, the directory dropped to 6.4 MB and 70 files, but new paired files appeared immediately, confirming active generation rather than a stale backlog.
The exact handler failure
Multiple reporters extracted the same fatal message from the newest .dmp files. It comes from Crashpad's own exception handler server, not from the Codex app or a renderer:
[FATAL:third_party/crashpad/crashpad/handler/mac/exception_handler_server.cc:76]
Check failed: kr == KERN_SUCCESS.
mach_port_request_notification: (os/kern) invalid capability (20)
The dumps carry annotations identifying the crashing process as the handler itself:
executable_path=/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/152.0.7977.64/Helpers/browser_crashpad_handler
--monitor-self-annotation=ptype=crashpad-handler
ptype=crashpad-handler
macOS's own diagnostic logs corroborate this. Reporters found repeated .ips entries under ~/Library/Logs/DiagnosticReports with procName: browser_crashpad_handler, exception: EXC_BREAKPOINT / SIGTRAP, and coalitionName: com.openai.codex.
Why the loop never terminates
User ReymondAkpanya supplied the clearest explanation of the self-sustaining cycle in a September 21, 2026 comment. Because the handler is launched with --monitor-self-annotation, it monitors itself. The sequence is:
- The handler calls
mach_port_request_notificationand receivesKERN_INVALID_CAPABILITY(20). - It hits the
CHECKatexception_handler_server.cc:76and dies. - The self-monitor writes a minidump of the handler.
- The handler is relaunched, fails the identical check, and returns to step 2.
That's a loop with no base case, which is why the growth is perfectly linear rather than correlated with any app activity.
Measured rate from that report: exactly one dump per second, 181,552 bytes each, plus a 24-byte _sidecar.json — roughly 3,600 dumps per hour, about 0.6 GB per hour, or approximately 15 GB per day while the app runs. In that case the queue reached 240,966 files and 21 GB and took a 228 GB disk down to 0 bytes free. The completed/ directory was empty across all 240,966 reports, meaning nothing ever drains the queue.
The upstream cause is not Codex-specific
The mach_port_request_notification / KERN_INVALID_CAPABILITY failure is a Crashpad-on-macOS Mach IPC problem, not something unique to Codex. The same error on macOS Tahoe 26.3.1 has been reported against other Chromium/Electron applications, including Claude Desktop (anthropics/claude-code#37230) and VS Code (microsoft/vscode#282433).
This distinction matters for anyone assessing the bug. The upstream CHECK failure is environmental. The unbounded disk consumption is not — any repeatable handler-startup failure produces the same runaway, because the self-monitor treats the handler's own fatal CHECK as a reportable crash. As ReymondAkpanya put it, the trigger is upstream but the amplification is not.
The retention bug is independent of the crash loop
User dewalt-1 made the strongest case that these are two separate defects. On September 2, 2026, they reported 174.6 GB in ~/Library/Application Support/Codex/Crashpad/pending against 171 MB for everything else in Application Support/Codex combined — 99.9% of the directory. The dumps were uniform ~161 KB pairs, about 1.08 million dumps and more than 2 million files.
Critically, that machine was not in a tight loop: the last write to pending/ was 16 hours earlier and the app had run since without adding to it. The Crashpad/ directory was created 2026-04-05, implying roughly 1.1 GB/day averaged over five months rather than 5–17 GB/day.
Whatever generates the dumps, nothing prunes them. The retention bug looks separable from any specific crash loop: even a low crash rate reaches 175 GB given five months. A size or age cap on pending/ would bound the damage independently of fixing the crashers.
User jakehop noted on August 9, 2026 that Crashpad ships with a pruner that is not implemented in this integration: "I've seen this behaviour in other Electron apps, where the handler is wired up but the pruner is not, and if telemetry is turned off or blocked, these logs will just pile up in pending."
Affected paths and versions
Two Crashpad database paths appear across the reports, and both can be affected on the same machine:
~/Library/Application Support/com.openai.codex/web/Crashpad/pending— the legacy path used by early Codex Desktop builds.~/Library/Application Support/Codex/Crashpad/pending— the newer path used by the unified ChatGPT/Codex desktop app.
ahmedkhan25 measured both simultaneously on October 17, 2026: 180 GB / 2,251,765 files in the legacy path and 143 GB / 1,785,095 files in the newer path, for a combined ~323 GB and ~4.04 million files — about 35% of a 926 GB disk. Free space had fallen to 1.4 GB before they found it.
Reported app versions span 26.527.60818 (June) through 26.1007.71326 build 20398 (October), with Chromium framework versions from 148.0.7778.179 to 155.0.8059.40. Affected macOS versions in the reports cluster on 15.x and 26.0–26.3.
Version and platform signals
Contributor dnakov commented on June 14, 2026: "I think this is fixed with later macos versions. at least in 26.5 it is." User nathanvy reported on October 18, 2026 being unaffected on macOS 26.6.2 running codex v26.1013.40934 build 20770.
That pattern — affected on 15.x and 26.0–26.3, unaffected on 26.5+ — is consistent with the Mach IPC failure being kernel-version dependent. However, the thread also contains reports on newer builds and newer paths, and libairi found that rolling back the app build alone would not help: build 5538 (26.715.31251) and build 5650 both use Chromium 150.0.7871.124, share the same Mach-O UUID, and have an identical SHA-256 hash for the unsigned code region.
Workarounds reported by users
1. Delete the pending reports
The simplest containment is to delete files directly inside the pending directory. The author's own cron entry, posted June 20, 2026:
*/15 * * * * /usr/bin/find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f -delete >/dev/null 2>&1 || true
Set it up with crontab -e and verify with crontab -l. This deletes only files directly inside the pending directory.
2. Make the pending directory read-only
Several users stopped the growth by removing write permission from the directory after emptying it. ReymondAkpanya's version:
P=~/Library/"Application Support"/Codex/Crashpad/pending
find "$P" -type f -delete
chmod 500 "$P"
They confirmed growth stops and nothing spills into new/, completed/, or attachments/ — the whole Crashpad directory stays at 20K. Reverse with chmod 700.
dionylon used a stronger variant on the whole database, combining chmod -R 555 with chflags -R uchg after recreating the pending, new, completed, and attachments subdirectories. That stopped pending at zero for the observed window. They noted macOS would not allow modifying the handler binary itself even with sudo (Operation not permitted).
3. Move files to Trash instead of deleting
User liuminsheng3 recommended moving only the Crashpad report buckets to Trash rather than deleting the whole app-data directory, and stopping the handler first:
osascript -e 'quit app "Codex"' 2>/dev/null || true
pkill -f "browser_crashpad_handler.*codex.*/Crashpad" 2>/dev/null || true
for crash in \
"$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \
"$HOME/Library/Application Support/Codex/Crashpad"; do
[ -d "$crash" ] || continue
mkdir -p "$HOME/.Trash/Codex-Crashpad"
for bucket in pending new completed attachments; do
[ -d "$crash/$bucket" ] || continue
find "$crash/$bucket" -mindepth 1 -maxdepth 1 -exec mv {} "$HOME/.Trash/Codex-Crashpad/" \;
done
done
This matters at scale: ahmedkhan25 reported that deleting millions of small files is slow, while renaming the folder is instant. its-tahir gave the same advice — "move the Crashpad folder to the Trash. That's instant even with millions of files, whereas rm on 4M files is slow."
4. Bounded retention via LaunchAgent
ashtonsix installed a LaunchAgent that runs every five minutes, expires reports older than 24 hours, and caps each pending/completed queue at 64 report groups and 256 MiB. It groups matching UUID dump/sidecar files, gives fresh writes a two-minute grace period, and skips unknown files, symlinks, and files that change during inspection. They explicitly framed this as bounding retained diagnostic storage without making the database unwritable — not as a repair for the crashing helper.
Workarounds that did not work
libairi tested several approaches on the unified app and reported all of them ineffective:
- Launching with
--disable-breakpaddid not prevent new Crashpad reports. - Denying execution of the handler stopped pending dumps but caused repeated macOS "ChatGPT quit unexpectedly" reports and popups.
- Periodically deleting only
Crashpad/pendingcontains disk usage but does not fix the handler crash loop.
dionylon also reported that a full reinstall did not fix it, and that disabling browser@openai-bundled, disabling chrome@openai-bundled, and setting BROWSER_USE_AVAILABLE_BACKENDS = "" in ~/.codex/config.toml did not stop the dump growth after restart.
Safety cautions on the read-only workaround
User liuminsheng3 warned that making Crashpad/pending read-only should be treated as an emergency brake, not a default cleanup path. It stops an active dump loop but also prevents Codex from writing crash reports and may hide the signal maintainers need. They recommended keeping the scope narrow and avoiding permanently read-only states on ~/Library/Application Support/Codex, ~/Library/Application Support/com.openai.codex, and temporary com.openai.codex.code_sign_clone directories.
Their suggested order: quit Codex; move only the Crashpad report buckets to Trash; restart and watch whether pending regrows; apply the read-only workaround only if it is actively refilling; and undo the read-only bit after the app or version issue is fixed.
How to check whether you are affected
its-tahir posted a compact triage summary in the thread. Check the size of both Crashpad paths:
du -sh "$HOME/Library/Application Support/Codex/Crashpad" \
"$HOME/Library/Application Support/com.openai.codex/web/Crashpad" 2>/dev/null
Check whether dumps are being written right now — roughly 60 .dmp files in the last minute means the loop is running:
find "$HOME/Library/Application Support/Codex/Crashpad/pending" \
-maxdepth 1 -name '*.dmp' -mmin -1 | wc -l
Then quit the app, check for leftover handlers with pgrep -fl browser_crashpad_handler, and move the Crashpad folder to the Trash.
Why the dumps should not be shared publicly
Every reporter who attached evidence withheld the raw .dmp files. The original author stated: "I am not attaching minidumps publicly because they may contain memory, local paths, or private data. I can share the newest .dmp privately if OpenAI maintainers provide a safe upload path." Multiple later commenters repeated the same caution, noting that dumps may contain memory, local paths, prompts, or project state. Metadata — counts, size, oldest and newest timestamps, app version, and which path is still growing — was considered sufficient for public triage.
Community reaction on Hacker News
The Hacker News discussion (156 points, 73 comments) focused less on the technical mechanism and more on the pattern. Several commenters noted this is not the first Codex bug with SSD-wear implications; one referenced a prior Codex infinite-logging issue.
"This is the second Codex bug that could have a big durability impact on your SSD, though not as severe as the first one which did infinite logging."
Others reported disk pressure from adjacent causes rather than Crashpad specifically. One commenter traced their disk usage to git worktrees duplicating build artifacts across concurrent features, plus heavy macOS swap from hitting memory limits. Another reported thousands of screenshots and artifacts left behind in Codex worktrees, and 90 GB of unnecessary validation tests generated on a Windows VM. That commenter added: "This is definitely a Codex thing and I've never seen this happen in Claude Code or Antigravity."
A separate commenter found 11 duplicate codex and codex-code-mode-host binaries, each about 300 MB, in ~/.bun/install/cache/@openai. Another reported 14 GB of tiny files in a .staging/marketplace directory.
Several comments were sharply critical of the four-month gap between the initial report and a fix. One noted that Crashpad's own pruner exists but is not wired up in this integration. Another observed that users were being asked to work around a bug in a core product rather than having it fixed.
Practical suggestions from the thread included relegating agent harnesses to Docker containers, using disk-visualization tools such as DaisyDisk to find the growth, and checking the storage section in the ChatGPT app settings, which shows used disk space.
What a fix would need to address
ReymondAkpanya proposed two independent mitigations that would each have prevented the worst outcomes:
- Stop the self-monitor from reporting the handler's own startup
CHECKfailure, or back off and rate-limit after N consecutive identical dumps. This breaks the loop regardless of the upstream cause. - Bound
pending/with a size cap or TTL, so a silently failing upload path cannot fill the disk.
Either one would have turned this from "disk at 0 bytes" into a log line.
ahmedkhan25 added three asks in the same spirit: a size or count cap on Crashpad/pending with automatic pruning; a fix for the handler crash loop; and an in-app warning when Codex's own data exceeds a few GB.
Status
The issue remained open with labels app, bug, and performance at the time of the source scrape. The most recent reports in the thread, from October 2026, describe the bug on app versions up to 26.1007.71326 build 20398 and on both Crashpad paths. A contributor comment suggested later macOS versions (26.5 and above) are unaffected, and one user on macOS 26.6.2 reported no impact — but the thread also contains newer-build reports and evidence that the handler binary is unchanged between adjacent builds. No official fix or retention limit had been confirmed in the thread.