Codex Crashpad 'pending' Eating Your Mac's Disk? Check, Clean and Stop It

If your Mac's disk is suddenly full and you use OpenAI's Codex desktop app (current builds ship as the unified ChatGPT desktop app, bundle ID com.openai.codex), check its Crashpad/pending folder. Its Chromium crash handler, browser_crashpad_handler, can get stuck writing a dump into it about once a second, roughly 15 GB a day, and nothing ever cleans it up. Quit the app, move the Crashpad folder to the Trash, then update macOS and the app so it doesn't come back.

The bug has been open on GitHub since June as openai/codex #25921, and it reached Hacker News in October 2026 with over 120 points. The numbers people report are not small: 59 GB, 114 GB, 168 GB, a combined 323 GB across 4 million files, and in one case 511 GB. The app keeps working the whole time, so most people only find it when the disk hits zero.

Where is the Codex Crashpad folder on a Mac?

Depending on your app build, the dumps go into one of two folders, and some Macs have both. In Finder, press Shift-Command-G and paste a path to open it:

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

In Terminal, this shows how much space each one is using:

for d in "$HOME/Library/Application Support/Codex/Crashpad" \
         "$HOME/Library/Application Support/com.openai.codex/web/Crashpad"; do
  [ -d "$d" ] && du -sh "$d"
done

To see whether it's still actively growing, count the dumps written in the last minute. Around 60 means the loop is running right now:

find "$HOME/Library/Application Support/Codex/Crashpad/pending" \
  -maxdepth 1 -name '*.dmp' -mmin -1 | wc -l

Run it against the com.openai.codex/web/Crashpad/pending path too if that's the one you have. With millions of files, these commands can take a while; one reporter noted that even listing the folder timed out.

I'm on Windows, so I haven't run these on a Mac myself. They're built from the commands reporters used in the GitHub issues. The Windows check further down is one I did run.

What the files look like

The folder fills with pairs: a .dmp minidump of about 181 KB and a tiny _sidecar.json. Open the crash report macOS keeps for browser_crashpad_handler, or the text inside a dump, and you'll see the same error every time:

[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)

If you see invalid capability (20) from exception_handler_server.cc:76, you have the Codex Crashpad loop described below.

Why is Codex Crashpad pending so big?

Codex Desktop is built on Chromium, which uses a small helper process, the crash handler, to write a report whenever something crashes. One reporter in the issue traced the dumps and found that the dumps they inspected were all of the crash handler itself, not of Codex:

1. browser_crashpad_handler starts and asks macOS for a notification port.
2. macOS refuses with invalid capability (20), and the handler stops on a failed check.
3. The handler watches itself, so its own crash is written to pending as a new dump.
4. It's relaunched, fails the same check, and the loop starts again.

They measured about one dump per second, roughly 0.6 GB an hour. Because nothing in the app prunes pending, the folder only ever grows. Another commenter pointed out that Crashpad ships with a pruning mechanism the app doesn't appear to use.

The same crash-handler error isn't unique to Codex. Claude Desktop hit the identical mach_port_request_notification failure on macOS Tahoe 26.3.1 in March (anthropics/claude-code #37230), and a VS Code issue shows the same error in its terminal. In Codex's case it turns into a disk problem because the reports pile up instead of being removed.

There's a second symptom once the folder is huge: one reporter found the app itself started crashing about a minute after launch, running out of memory as it dealt with the backlog. If Codex won't stay open, clean the folder first.

Is it safe to delete Codex Crashpad pending?

The dumps are crash reports, not your projects, settings or conversations, so removing them is safe. Do it carefully, though. These commands are written for Terminal, and none of them deletes anything outright:

1. Quit the app with ⌘Q. On current builds it's the ChatGPT app; older ones are called Codex.

2. Stop a leftover crash handler. In the original report, two crash-handler processes were running on their own, detached from the app. After quitting, list any that are left:

pgrep -fl browser_crashpad_handler

Each line starts with a process ID. Stop only the ones whose path is inside the Codex or ChatGPT app (it contains Codex.app, ChatGPT.app or Codex Framework), one at a time:

kill 12345   # the process ID from the line above

3. Move the Crashpad folders to the Trash. Moving a folder within the same disk is instant, even with millions of files inside:

cd "$HOME/Library/Application Support" || exit
[ -d "Codex/Crashpad" ] && mv "Codex/Crashpad" "$HOME/.Trash/Codex-Crashpad-$(date +%s)"
[ -d "com.openai.codex/web/Crashpad" ] && mv "com.openai.codex/web/Crashpad" "$HOME/.Trash/codex-web-Crashpad-$(date +%s)"

If Terminal says Operation not permitted, macOS is protecting the Trash from it. Open the folder in Finder (Shift-Command-G, paste the path) and drag the Crashpad folder to the Trash instead.

4. Empty the Trash. With millions of small files this can take a long time, but space comes back as it goes. One reporter went from 1.4 GB free to more than 50 GB within minutes.

Don't delete the whole ~/Library/Application Support/Codex folder unless you want a full reset of the app. Only the Crashpad folder is the problem, and Chromium-based apps normally recreate it on their own when they next need it.

5. Reopen the app and check again after a few minutes with the find … -mmin -1 command above. If new dumps are still arriving every second, the loop is still running, and the next section is what stops it.

How do I stop Codex Crashpad dumps coming back?

Update macOS. An OpenAI contributor said on October 6, on a related issue that reported 511 GB: "This seems to be an issue for older mac kernels. A fix has been merged and will be released soon." The reports line up with that. Every affected Mac I found in the threads was on macOS 15.x or Tahoe 26.0–26.3, while people on 26.5 and 26.6.2 said it doesn't happen to them. That's a pattern from user reports, not an official version boundary.

Update the app. As of October 18 the fix isn't mentioned in OpenAI's changelog, and one person still saw the loop on app build 26.1007 with macOS 15.7.4. Keep the app updated and re-check the folder after each update.

If you can't update yet, use a brake. People in the issue used two stopgaps:

• A scheduled cleanup that empties pending every 15 minutes, so it never gets big.
• Making pending read-only, so the handler can't write there at all:

# run after the app has recreated the pending folder
for d in "$HOME/Library/Application Support/Codex/Crashpad/pending" \
         "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending"; do
  [ -d "$d" ] && chmod a-w "$d"
done
# undo later, once you're on a fixed version: the same loop with chmod u+w

Reporters said the read-only trick stopped the disk growth, though the handler keeps crashing in the background. It also stops genuine crash reports, which is the signal OpenAI needs to fix crashes. Treat it as temporary and undo it after updating.

On Windows

Every report I found is from macOS. The failing check lives in Crashpad's Mac exception handler, so I wouldn't expect the same loop on Windows.

I checked on my own Windows 11 machine, which has Codex 26.1013 installed from the Microsoft Store. Its crash reports live under the app's package folder, and there is no pending folder at all, just reports and attachments:

%LOCALAPPDATA%\Packages\OpenAI.Codex_<id>\LocalCache\Roaming\Codex\web\Codex\Crashpad

This PowerShell one-liner shows how much it holds:

$c = @(Get-ChildItem "$env:LOCALAPPDATA\Packages\OpenAI.Codex_*\LocalCache\Roaming\Codex\web\Codex\Crashpad" -Recurse -File -ErrorAction SilentlyContinue)
"{0} files, {1:N1} MB" -f $c.Count, (($c | Measure-Object Length -Sum).Sum / 1MB)

On my machine it printed 0 files, 0.0 MB. If your Windows disk is filling up, look elsewhere first, such as build artifacts in agent worktrees, which came up a lot in the Hacker News thread.

Quick reference

Desktop AI apps are now big, always-running pieces of software on developer machines, and they fail in ways the agent itself can't see, as the SneakPeek preview-pane flaw in Claude Desktop showed. If it's your coding agent that's slow or eating memory rather than disk, see Claude Code slow, hanging or eating memory. I help teams roll out AI coding tools on company machines. See recent projects.