One open report reached 323 GB
An open issue in the OpenAI Codex repository documents pending Crashpad reports that accumulated while the desktop app stayed usable. The original reporter measured 4.9 GB and 54,504 files in one day. An October 17 comment reported about 323 GB across an older and a newer Crashpad path. The issue remained open when this dispatch was published.[1]
Those numbers are user reports. OpenAI has not confirmed one cause for every machine in that thread. Several comments contain detailed process and dump observations, but the thread also records different app versions, paths, rates, and operating system versions. Treat the path and growth pattern as a lead to inspect, not a verdict for your machine.
Disk pressure is a symptom. The writer, file class, and recovery handle decide the fix.
Separate app data from project data
Crashpad reports belong to an application support directory. Codex session history belongs under CODEX_HOME. Worktrees and their build output belong to repositories and build systems. macOS swap belongs to the operating system. A single cleanup command cannot respect all four ownership boundaries.
OpenAI's advanced configuration guide says Codex stores local session transcripts under CODEX_HOME. It documents history.max_bytes as a cap for the history file. That setting does not claim to cap Crashpad reports, worktree output, screenshots, or operating system swap.[2]
The Hacker News discussion around the open issue includes separate reports of duplicated build output, screenshots, validation artifacts, and worktrees. Those comments establish that developers are seeing several kinds of disk pressure at once. They do not prove that Codex created every file or that every worktree is disposable.[3]
Run the cheap probe first
This probe reads the two Crashpad paths reported in the issue. It does not open dump contents, count millions of directory entries, delete files, or change permissions.
for p in \ "$HOME/Library/Application Support/Codex/Crashpad" \ "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" do [ -d "$p" ] || continue printf '\n%s\n' "$p" du -sh "$p" "$p/pending" 2>/dev/null stat -f 'modified=%Sm' -t '%Y-%m-%d %H:%M:%S' "$p/pending" 2>/dev/null done
Run it again after one minute. A changing size or modification time indicates active writes. A flat result identifies a backlog, not its cause.
Do not start by counting every file. Several issue reports describe queues with more than one million entries. Enumeration can be slow while the disk is already under pressure. Size and modification time answer the first question with less work.
Stop growth before reclamation
If a Crashpad path is growing, quit the desktop app and confirm that no Crashpad handler still writes to that database. Preserve the app version, path, size, oldest and newest times, and a private support route before moving report buckets. Dump files may contain process memory, paths, prompts, or project data. Do not post them in a public issue.
Reclaim the narrow layer you inspected. Moving only known report buckets to Trash keeps the broader application state out of the deletion. Making an application directory read-only can hide diagnostics and break updates, so keep that move as an emergency brake with a rollback plan. A cleanup that stops growth for five minutes is containment. It is not proof that the app defect is fixed.
Worktree cleanup needs a custody check
Git's manual says a linked worktree has its own working tree, HEAD, and index while sharing repository data. The supported removal command refuses a dirty worktree unless the operator uses force. git worktree prune removes stale administrative records for missing working trees. It does not delete a present worktree or its build output.[4]
Before removal, record the branch or detached revision. Check tracked edits, untracked files, ignored build output, running services, and the pull request or commit that accepted the work. Remove the worktree with Git after that review. Use prune --dry-run only to preview stale administrative cleanup.
The service order is simple. Locate the path. Classify the files. Stop the writer. Preserve the rebuild handle. Then reclaim one known layer.