Codex desktop app filling your Mac's disk? Check Crashpad/pending — where the dumps live, how to clear them, and what OpenAI hasn't fixed yet

If your Mac’s free space keeps shrinking and you run the Codex desktop app (now shipped as the unified ChatGPT app with bundle ID com.openai.codex), check one folder before anything else: Crashpad/pending. GitHub issue openai/codex #25921, opened on June 2, 2026, reached the Hacker News front page on October 17, 2026, and it is still open with bug, app and performance labels. The question for builders: is my machine affected, what is safe to delete, and is there a fix?

What is happening

The app’s bundled browser_crashpad_handler keeps writing pairs of .dmp minidumps and _sidecar.json files into its Crashpad pending directory. They never upload and never expire, and the app keeps working normally, so nothing warns you until the disk is nearly full.

Numbers reported in the thread and its sister issue:

Report	App build	Crashpad size
Original report, June 2	26.527.60818	4.9 GB, 54,504 files in one day
#36982, Aug 4	26.727.51351	about 17 GB/day; a 228 GB disk went from 34 GB free to 0 in 48 hours
Sep 21 comment	26.831.21537	one dump per second, about 15 GB/day while the app runs
Oct 17 comment	26.1007.71326	about 323 GB and 4.04 million files across both paths

The September commenter found that every dump is of the crash handler itself, which fails a Mach port check (mach_port_request_notification: (os/kern) invalid capability (20)), dies, gets dumped by its own self-monitor and is relaunched. The same Crashpad error has been reported against Claude Desktop on macOS Tahoe 26.3.1, so the trigger looks like a Crashpad and macOS issue. The unbounded disk growth comes from nothing pruning pending/.

Check both folders

Reports name two locations, an older one and the one used by newer unified builds:

• ~/Library/Application Support/com.openai.codex/web/Crashpad
• ~/Library/Application Support/Codex/Crashpad

A quick size check:

du -sh ~/Library/"Application Support"/com.openai.codex/web/Crashpad \
       ~/Library/"Application Support"/Codex/Crashpad 2>/dev/null

If either shows gigabytes, almost all of it will be in pending/. On very large folders even listing files can be slow; one commenter’s directory had hit the 65,535 link-count limit.

Cleanup steps users posted

There is no official OpenAI cleanup guidance in the issue. The narrowest approach suggested in the thread:

1. Quit the app.
2. Move only the Crashpad report buckets (pending, new, completed, attachments) to the Trash. Don’t delete the whole Application Support/Codex folder unless you want a full local reset.
3. Restart the app and watch whether pending starts growing again.

Users who did this got the space back right away. Several also saw new dump pairs show up within minutes, so cleanup alone doesn’t stop the loop. Don’t attach .dmp files to public issues; they can contain memory contents, local paths and project data.

The read-only workaround: last resort only

Two commenters stopped the growth by emptying pending and removing write permission (for example chmod 500 on the folder). It works, but it also stops the app from recording any crash reports. Another commenter advised treating it as an emergency brake and undoing it once a fixed build ships. Some users run a cron job every 15 minutes that deletes files in pending instead.

Is it fixed?

Not as of October 18, 2026. One contributor suggested in June that newer macOS versions fixed it, but later reports cover macOS 15.6 through 15.7.4 and 26.0.1 through 26.3.1 on builds up to 26.1007.71326. A separate request, #51361, asks for default storage caps and automatic cleanup for Codex-generated data. A related bug, #25667, reports roughly 965 MB code_sign_clone folders left behind in /private/var/folders after each launch. Those are cleared on reboot.

If Codex is your daily agent, add a du check of these paths to your routine until OpenAI ships a cap. For more Codex desktop context, see our notes on Codex Record & Replay and the Claude Code vs Codex head-to-head.