Codex Desktop 持续生成 Crashpad 待处理转储,磁盘占用无上限增长至约 323GB
Codex Desktop continuously generates Crashpad pending dumps
Codex Desktop 被曝持续生成 Crashpad pending 转储且无任何上限,用户实测 2026-10-15 至 10-17 期间两个 Crashpad 目录合计约 323GB、约 404 万个文件,占 926GB 磁盘的约 35%,剩余空间一度降至 1.4GB 且应用无任何提示。
changed the title
on Jun 9, 2026[-]Codex Desktop continuously generates Crashpad pending dumps, growing to ~5GB[/-][+]Codex Desktop continuously generates Crashpad pending dumps, growing without any limit: +5GB per day at least[/+]Still happening on the current build, and at a much larger scale. Measured 2026-10-15 to 2026-10-17:
Environment
- ChatGPT.app
26.1007.71326(build20398), Codex Framework (Chromium)155.0.8059.40 - macOS
15.7.4, Apple Silicon (arm64)
What I found
Folder Size Files ~/Library/Application Support/com.openai.codex/web/Crashpad180 GB 2,251,765 ~/Library/Application Support/Codex/Crashpad(almost all of it inpending/)143 GB 1,785,095 Total ~323 GB ~4.04 million That was about 35% of a 926 GB disk. Free space fell to 1.4 GB before I found it. Nothing in the app warned me. I only found it by running
duover~/Library.The app kept working the whole time, as others have reported here. So the dumps build up silently in the background with no limit.
Cleanup
With the app still running, I renamed both
Crashpadfolders and deleted the renamed copies. Free space went from 1.4 GB to 50+ GB within minutes, and the delete is still running (millions of small files).Asks
- Put a size or count cap on
Crashpad/pending, with automatic pruning (see also Add storage limits and automatic cleanup for Codex-generated data #51361). - Stop the handler crash loop that produces the dumps ([app][macOS][26.727.51351] browser_crashpad_handler SIGTRAPs 2ms after launch, launchd respawns it, Crashpad/pending fills disk at ~17GB/day #36982).
- Show a warning in the app when its own data goes over a few GB.
- ChatGPT.app
来源:Hacker News · github.com