Codex Desktop 持续生成 Crashpad 待处理转储文件,无上限增长单日超 5GB
Codex Desktop continuously generates Crashpad pending dumps
用户实测发现 Codex Desktop 在 macOS 端持续生成 Crashpad 待处理转储文件,两天磁盘占用约 323GB,单日增长超过 5GB。
原文给出具体的 Crashpad 堆积体量、复现版本与环境,读者可据此自行核对本地是否受影响,也可观察官方后续修复进展。
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