- Book: System Design Pocket Guide: Fundamentals
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
On October 17, a Mac user added a table to a Codex GitHub issue that had been open since June 2. Two crash-report folders, about 4 million files, roughly 323 GB. "That was about 35% of a 926 GB disk," they wrote. "Free space fell to 1.4 GB before I found it."
The issue's title describes the bug in one line: "Codex Desktop continuously generates Crashpad pending dumps, growing without any limit: +5GB per day at least." LavX News wrote it up on October 18.
If you run the desktop app of Codex on a Mac, checking your own disk takes a few minutes. Every report linked below is about the desktop app on macOS. I haven't reproduced it on my own machine.
What the reports say
These numbers come from users in the issue tracker and the OpenAI forum. None of them is an OpenAI measurement.
- The original report, on June 2, counted 4.9 GB and 54,504 files in one day.
- Issue #36982, filed against app version 26.727.51351, puts the rate at "~17GB/day".
- Issue #47466, opened September 23 on macOS 15.2, reports the folder at about 511 GB, with one minidump of roughly 160 KB about once per second while the app is open.
- Issue #51361, on October 6, reports 130.53 GiB, about 821 MiB of free space left, and temp files failing with "no space left on device".
- Issue #52194, on October 8, reports about 168 GB and roughly 1.97 million files.
- A forum post on October 16 estimates about 230 GB of crash reports.
- The October 17 comment names its build: ChatGPT.app
26.1007.71326.
The app keeps working while this happens. The first reporter noted it stayed usable, which is why the folder can grow for weeks before anyone looks.
Why the folder never empties
Crashpad is the crash reporter from the Chromium project, "a library for capturing, storing and transmitting postmortem crash reports". Its database holds "crash dumps pending upload." Those are the files in the pending folder.
The leading explanation comes from users, not from OpenAI. In #25921, one reporter found that every dump is of the crash handler itself, browser_crashpad_handler, and several others quote the same startup failure. Its call to mach_port_request_notification returns "(os/kern) invalid capability (20)", a check fails with Check failed: kr == KERN_SUCCESS., and the process dies. It is restarted, fails again, and writes another dump. The title of #36982 sums it up: the handler "SIGTRAPs 2ms after launch, launchd respawns it". One commenter in #25921 reports the same error in other Chromium and Electron apps on macOS Tahoe 26.3.1.
The second half of the problem is that nothing trims the folder. Crashpad's design doc says "The database stores a configurable number of recorded crash dumps to a configurable maximum aggregate size." A commenter in #25921 says the app doesn't use Crashpad's pruner. Issue #51361 asks OpenAI to turn on storage limits and cleanup by default, and it is still open with no assignee.
Is it fixed?
Partly, maybe. On October 6, a contributor on the repo wrote in #47466: "This seems to be an issue for older mac kernels." In the same comment: "A fix has been merged and will be released soon." The issue was closed that day. On October 7, a user asked which released build has the fix and whether it cleans up queues that are already huge. No answer appears in that thread.
Earlier, on June 14, a contributor wrote in #25921: "I think this is fixed with later macos versions. at least in 26.5 it is". Later reporters on macOS 26.0 to 26.3 still saw growth, and the #47466 report came from macOS 15.2.
The October 17 report is on build 26.1007.71326, on macOS 15.7.4. Whether that build carries the October 6 fix, the thread doesn't say. #25921 is still open.
One more data point from #52194: its reporter found two handler processes from an older framework version still running, though that version was no longer on disk. Killing processes didn't help. A macOS reboot stopped the loop for them.
Check your Mac
The issue lists two locations: an older one and a newer one. Measure both with du:
cd ~/Library/"Application Support"
du -sh Codex/Crashpad/pending \
com.openai.codex/web/Crashpad/pending 2>/dev/null
If the result is in gigabytes, dumps are piling up. To see whether it is still growing, count the files with find and measure twice, a minute apart, with the app open. This runs from the same folder. If com.openai.codex/web/Crashpad/pending was the big one, swap that path in:
find Codex/Crashpad/pending -type f | wc -l
du -sh Codex/Crashpad/pending; sleep 60
du -sh Codex/Crashpad/pending
Then check whether a handler process is running:
pgrep -lf browser_crashpad_handler
If the folder is big
Quit the app first. The #52194 reporter says OpenAI support told them to clear pending reports with the app closed. A running handler keeps adding new dumps while you delete. With millions of files, rm pending/* fails because the shell expands every name into one argument list. find -delete walks the folder instead:
cd ~/Library/"Application Support"
find Codex/Crashpad/pending -type f -delete
Run the same line for com.openai.codex/web/Crashpad/pending if that one was large too. Then reboot, which is what worked in #52194, reopen the app and run the growth check again.
If the folder still grows, users in #25921 run cleanup on a timer until a fixed build lands. This removes dumps older than 24 hours:
find Codex/Crashpad/pending -type f -mtime +0 -delete
Some commenters made pending read-only with chmod instead. Others warned that this also blocks real crash reports from reaching OpenAI, so if you do it, undo it after you update.
Any local queue you ship needs a cap
A folder that only drains when an upload succeeds is a queue. When the consumer never runs, the queue grows until the disk is full, and nothing in the app looks wrong. Crashpad already has the two limits that would have contained this: a count and a total size. They have to be set.
The same goes for what your own tools write: agent transcripts, retry queues, debug logs, crash reports. Give each one a size limit and an age limit, and have it write less when the disk is nearly full, which is what #51361 asks Codex to do.
If this was useful
If you run Codex next to Claude Code and other agents, I build Hermes IDE, so weigh this with that in mind: it is free to download, source-available, runs on macOS, Windows and Linux, and can give each task its own branch and worktree, so agents don't step on each other (GitHub).
An unbounded queue with a consumer that never runs is a classic system design failure, and it shows up far from crash reporters. The System Design Pocket Guide: Fundamentals covers the building blocks underneath stories like this one, from rate limits to availability, so one stuck component doesn't take the whole system down with it.
Top comments (1)
what part of Codex's crash reporter spawns a separate file per crash instead of rotating or aggregating them, and can it be hooked to enforce a size or count limit
have you experimented with redirecting those dumps to a temporary location or adding a pruning policy to keep the file count manageable