Codex Desktop continuously generates Crashpad pending dumps
github.com
October 17, 2026
24 min read
52/100
Summary
Users report that Codex Desktop and the unified ChatGPT/Codex macOS app can continuously accumulate Crashpad crash-report files in local pending directories while the app remains usable. The files appear as paired .dmp minidumps and _sidecar.json metadata under ~/Library/Application Support/com.openai.codex/web/Crashpad/pending in older installs and ~/Library/Application Support/Codex/Crashpad/pending in newer ones. Reported storage consumption ranges from 4.9 GB and 54,504 files in a day to more than 300 GB across both paths, with millions of files and little or no warning before disks approach capacity. Several users identified repeated crashes of the Electron/Chromium browser_crashpad_handler helper. Dumps cited a fatal mach_port_request_notification failure, KERN_INVALID_CAPABILITY, followed by EXC_BREAKPOINT or SIGTRAP reports. One reporter said the handler’s self-monitoring configuration causes a new dump whenever the handler itself fails, producing roughly one dump per second, or about 15 GB daily. Other reports describe large inactive backlogs, indicating that missing retention or pruning can also consume substantial storage without an active crash loop. Deleting pending reports recovers space but may not prevent regrowth. Users have temporarily contained growth by periodically deleting reports or making Crashpad directories read-only, although those measures prevent crash-report writing. Reports call for a handler fix plus built-in size, age, or count limits for pending reports.
Key Takeaways
- Codex and ChatGPT/Codex for macOS have been reported to accumulate paired Crashpad minidumps and sidecar files without an effective retention limit, even while the app remains functional.
- Some reports link rapid growth to browser_crashpad_handler repeatedly failing with a mach_port_request_notification KERN_INVALID_CAPABILITY error and generating dumps of itself.
- Reported Crashpad storage use ranges from several gigabytes per day to more than 300 GB across legacy and current application-data paths.
- Deleting Crashpad pending files can immediately reclaim disk space, but new reports may resume unless the underlying failure stops or writes are blocked.
- Users have requested automatic pruning and strict storage caps so failed crash-report uploads or recurring helper crashes cannot exhaust local disks.
What the discussion said
The thread treats the crash-dump report as part of a broader operational problem: autonomous coding agents are unexpectedly expensive tenants on a developer machine. Readers describe Codex filling disks not only with pending crash dumps, but with screenshots, validation suites, build outputs, logs, stale worktrees, cached binaries, and documentation. The practical consequence is brutal: a few parallel tasks can consume tens or hundreds of gigabytes, trigger memory pressure and swapping, and turn local development machines into cleanup jobs. There is broad agreement that Codex needs sane retention and cleanup defaults, especially when it has authority to run builds and tests repeatedly. Several commenters are angry that a known disk-hogging failure mode appears to have persisted while the product is marketed around increasingly grand capabilities. The useful countercurrent is operational rather than defensive: isolate agents in VMs or containers, inspect storage with disk-visualization tools, compress logs, archive old sessions, and share build caches where possible. A smaller dispute concerns blame. Some see this as distinctly worse behavior from Codex than rival agent tools; others point out that Claude can strand huge workspaces too, while Rust's build artifacts and worktree-heavy workflows amplify any agent's mess. Nobody argues that leaving unlimited artifacts behind is acceptable.
Where opinion split
The sharpest dispute is whether Codex is uniquely reckless with disk or merely exposes an ecosystem-wide agent-build problem. Critics cite huge piles of Codex-created screenshots, tests, logs, binaries, and crash dumps that competing tools supposedly do not produce; the other side notes that rival agents also abandon multi-gigabyte workspaces and that Rust builds, duplicate worktrees, and local cache design magnify the damage.
Community Sentiment
Positives
- Putting coding agents in containers or remote VMs contains runaway builds and lets them consume storage without turning a developer laptop into the blast radius.
- Filesystem compression, shared build caches, and session archival can substantially soften agent-generated logs and artifacts while teams wait for better defaults.
- Disk-visualization tools are proving unexpectedly valuable for AI coding workflows, making hidden agent caches, stale worktrees, and duplicated binaries visible enough to remove.
Concerns
- Codex appears to retain crash dumps, screenshots, validation suites, logs, and old build outputs indefinitely, so ordinary agent use can silently consume tens or hundreds of gigabytes.
- Running many subagents turns parallel development into a storage explosion, with each worktree reproducing heavy build artifacts and exhausting local memory as well as disk.
- Commenters see a glaring product-priority failure in promoting frontier reasoning while a basic desktop-agent bug can reportedly swallow hundreds of gigabytes of user storage.
- The agent's tendency to generate excessive validation material and preserve every intermediate result makes cleanup instructions part of the prompt rather than a safe default.
