I am seeing the same issue on macOS with a newer Codex Desktop build, with a bit more diagnostic detail.

Environment

• Product: Codex Desktop app on macOS
• Codex app version: 26.602.71036
• CFBundleVersion: 3685
• Framework/Crashpad annotation observed in dumps: ver=149.0.7827.54
• Architecture: arm64
• Crashpad database path:

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

Impact observed

The pending directory grew to about 61G:

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

Counts from the pending directory before cleanup:

files: 738,864
.dmp files: 369,431
_sidecar.json files: 369,433
bytes: 63,233,668,274
GiB: 58.89
recent_24h files: 98,218
recent_7d files: 573,480
oldest: 2026-06-01 10:52:52
newest: 2026-06-09 10:00:26

After cleanup/reinstall/restart, the directory continued growing at roughly one crash report per second:

10:28:46 files=142 MiB=11.63
10:28:51 files=152 MiB=12.44
10:28:56 files=162 MiB=13.26
10:29:01 files=172 MiB=14.08
10:29:06 files=182 MiB=14.89

Key diagnostic detail

The newest .dmp files contain this FATAL message from browser_crashpad_handler itself:

browser_crashpad_handler
Codex_Mac
crashpad-handler
[0609/103121.674299: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)
executable_path=/Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/149.0.7827.54/Helpers/browser_crashpad_handler
--database=/Users/<user>/Library/Application Support/com.openai.codex/web/Crashpad
--annotation=prod=Codex_Mac

So in this case it looks like browser_crashpad_handler is crashing/restarting in a loop and writing paired .dmp / _sidecar.json files for itself.

System diagnostic logs also show repeated browser_crashpad_handler crashes with:

procName: browser_crashpad_handler
procPath: /Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/149.0.7827.54/Helpers/browser_crashpad_handler
coalitionName: com.openai.codex
exception: EXC_BREAKPOINT / SIGTRAP

Related behavior

The in-app browser / Browser Use had previously become unavailable on this machine. During investigation, Codex logs repeatedly showed Browser Use / IAB lifecycle entries, and browser_use_availability_resolved available=true shortly before Crashpad kept generating dumps. That may or may not be the trigger, but the issue appears tied to the Codex Desktop browser/Chromium/Crashpad path.

A reinstall did not fix it.

Disabling browser@openai-bundled, disabling chrome@openai-bundled, and setting BROWSER_USE_AVAILABLE_BACKENDS = "" in ~/.codex/config.toml also did not stop the dump growth after restart.

Temporary workaround that stopped disk growth

Because macOS would not allow modifying /Applications/Codex.app/.../browser_crashpad_handler even with sudo (Operation not permitted), I worked around it by making the user Crashpad database read-only and immutable:

crash="$HOME/Library/Application Support/com.openai.codex/web/Crashpad"
pkill -f "browser_crashpad_handler.*com.openai.codex/web/Crashpad" 2>/dev/null || true
chflags -R nouchg "$crash" 2>/dev/null || true
chmod -R u+w "$crash" 2>/dev/null || true
rm -rf "$crash/pending" "$crash/new" "$crash/completed" "$crash/attachments"
mkdir -p "$crash/pending" "$crash/new" "$crash/completed" "$crash/attachments"
chmod -R 555 "$crash"
chflags -R uchg "$crash"

After that, pending stayed at zero for the observed window:

10:40:12 files=0 MiB=0.0
10:40:17 files=0 MiB=0.0
10:40:22 files=0 MiB=0.0
10:40:27 files=0 MiB=0.0
10:40:32 files=0 MiB=0.0
10:40:37 files=0 MiB=0.0
10:40:42 files=0 MiB=0.0
10:40:47 files=0 MiB=0.0

This is only a disk-growth workaround, not a real fix, since it effectively prevents Codex from writing Crashpad reports.