Codex Desktop for Mac piles up Crashpad dumps, GitHub bug report says

A bug report (#25921) in the openai/codex repository says Codex Desktop on macOS keeps adding paired .dmp and _sidecar.json Crashpad files to ~/Library/Application Support/com.openai.codex/web/Crashpad/pending. On the reporter's machine (app version 26.527.60818, macOS 26.3.1, arm64) the directory grew to 4.9G and 54,504 files in one day: 27,252 .dmp files and 27,252 _sidecar.json files. The sampled files ran from 2026-06-02 13:31:21 to 21:08:24 CEST, and during the investigation the total rose from 53,444 to 54,064 and then 54,504, which the reporter reads as live dump generation rather than stale leftovers.

The app itself keeps working. The reporter could use it, inspect the filesystem and file the issue from the same session, so this is not a launch failure or a foreground crash. The problem is unbounded local disk growth. The reporter also saw two browser_crashpad_handler processes running under PPID=1 since Sat May 30 11:47:50 2026, both using the same Crashpad database, and writes that it looks like Crashpad or a monitored helper process is repeatedly generating pending dumps without bounding, cleanup or rotation. That is the reporter's reading, not a confirmed cause. The reporter did not attach any minidumps publicly because they may contain memory, local paths or private data, and offered to share the newest one privately if OpenAI maintainers provide a safe upload path. The issue links three possibly related reports: #25259 (a stale Crashpad helper left after an update), #11090 (orphaned Codex processes and UI freezes) and #10627 (earlier Crashpad and macOS startup reports).

On June 2 the issue author, Jolg42, added an update. After deleting the files in the pending directory, the folder dropped from 4.9G and 54,504 files to 6.4M and 70 files (35 .dmp, 35 _sidecar.json). So most of the space was recoverable, but new pairs appeared immediately afterward, which the author takes as evidence that generation is still active.

A second commenter reported the same behaviour on a newer build, 26.602.71036 (arm64, Crashpad annotation ver=149.0.7827.54), at much larger scale. Before cleanup the pending directory held 738,864 files (369,431 .dmp and 369,433 _sidecar.json), 63,233,668,274 bytes, which the commenter gives as 58.89 GiB and describes as about 61G. Files dated from 2026-06-01 10:52:52 to 2026-06-09 10:00:26, with 98,218 files in the last 24 hours and 573,480 in the last 7 days. After cleanup, reinstall and restart the directory kept growing at roughly one crash report per second.

This commenter found what looks like the loop. The newest .dmp files contain a FATAL message from browser_crashpad_handler itself, from exception_handler_server.cc: "Check failed: kr == KERN_SUCCESS. mach_port_request_notification: (os/kern) invalid capability (20)". System diagnostic logs show repeated browser_crashpad_handler crashes with EXC_BREAKPOINT / SIGTRAP. The commenter concludes that the handler is crashing and restarting in a loop and writing dump and sidecar files for itself. The in-app browser / Browser Use had earlier become unavailable on that machine, and logs showed it resolving as available shortly before the dumps kept coming; the commenter says that may or may not be the trigger. A reinstall did not help. Disabling the browser@openai-bundled and chrome@openai-bundled plugins and setting BROWSER_USE_AVAILABLE_BACKENDS to an empty value in ~/.codex/config.toml did not stop the growth either.

The commenter's stopgap: macOS would not allow modifying the handler binary inside Codex.app even with sudo, so they killed the handler, recreated the Crashpad subfolders empty, then made the whole Crashpad database read-only (chmod 555) and immutable (chflags uchg). Pending then stayed at zero files over the observed window. The commenter stresses this is only a disk-growth workaround, not a real fix, since it effectively prevents Codex from writing Crashpad reports.

Other commenters add short notes. One says they cleaned up 22G in a day. Another reports the same issue on version 26.601.10930 and tags @dnakov. Another thinks it is fixed in later macOS versions, at least in 26.5. One more says each JSON is just 2 bytes plus a 150KB dump and that crash reports are also being generated under /System/Library/Caches/com.apple.coresymbolicationd/data, and shares a shell script to check recently changed files. The issue title was changed on June 9 from "growing to ~5GB" to "growing without any limit: +5GB per day at least".

Key facts

The reporter's Crashpad pending folder for Codex Desktop on macOS (version 26.527.60818) grew to 4.9G and 54,504 files in one day: 27,252 .dmp plus 27,252 _sidecar.json files.
Deleting the files freed the space (down to 6.4M and 70 files), but new dump pairs appeared immediately, so generation is still running.
A commenter on build 26.602.71036 reports 738,864 files and about 61G, a growth rate of roughly one report per second after cleanup and reinstall, and FATAL messages from browser_crashpad_handler itself (invalid capability, mach_port_request_notification).
The app stays usable throughout; the harm is unbounded disk use. A commenter's read-only, immutable Crashpad folder stops the growth but also blocks Crashpad reports, so it is a workaround, not a fix.
No cause is confirmed and no maintainer response appears in the visible thread; one commenter thinks later versions fix it.

Why it matters

Nothing visibly breaks, so the problem can go unnoticed until the disk fills. The reporter's folder reached 4.9G in a day, and a commenter on a newer build reports about 61G, enough that one person says it explains why their Mac's storage keeps filling up. The newer build's logs point to the Crashpad handler crashing and restarting in a loop and dumping reports about itself, which is a different picture from the first report's guess about a monitored helper process.

Who it affects

Users of the Codex Desktop app on macOS. The two detailed reports are both on arm64: the original on app version 26.527.60818 and macOS 26.3.1, the second on 26.602.71036. Another commenter reports the same on 26.601.10930 and a third cleaned up 22G in one day. No count of affected users is given, and the visible thread covers macOS only.

How to use it

This is a bug report, not a product to adopt, but the thread has practical steps. To check, the reporter measures the folder with du -sh on ~/Library/Application Support/com.openai.codex/web/Crashpad/pending and counts files with find. Deleting the pending files recovers the space, though they refill at once if the fault is active. One commenter stopped the growth by killing the handler, recreating the Crashpad subfolders empty, and making the Crashpad database read-only and immutable with chmod 555 and chflags uchg. That commenter says it is only a workaround because it prevents Codex from writing Crashpad reports at all. Disabling the bundled browser and chrome plugins and clearing BROWSER_USE_AVAILABLE_BACKENDS did not help, and neither did reinstalling.

How solid is it

It is a user-filed GitHub issue with measured file counts, sizes, build numbers and shell commands, and a second reporter with a different build and matching symptoms, so the growth itself is well documented. The causes are not established: the first reporter says it "looks like" Crashpad or a helper process, and the second says the Browser Use path "may or may not be the trigger". No response, acknowledgement or fix from OpenAI maintainers appears in the visible text, and no fixed app version is named. One commenter thinks it is fixed in later versions, at least in 26.5, but that is a single comment.

Risks and caveats

The immutable-folder workaround blocks Crashpad from writing reports and needs shell commands that change file flags, so it should be treated with care. The second commenter says the Crashpad handler inside Codex.app cannot be modified even with sudo. The original reporter withheld the minidumps because they may contain memory, local paths or private data, which is also a reason to be careful with them. The thread includes frustrated comments about code quality that are opinion, not evidence. The issue concerns macOS only as far as the visible text goes; it does not say whether Windows or Linux are affected.

“The Codex Desktop app is still functional while this is happening.”

— Issue author, GitHub issue #25921 in openai/codex