Codex 桌面版 Crashpad 错误（问题 #25921）：无限制的待处理转储文件填满 macOS 磁盘

OpenAI 的 Codex 桌面版 macOS 应用持续将 Crashpad 崩溃转储文件写入本地 pending 目录，且没有大小限制、没有生存时间、也没有清理机制，因此该文件夹会无限增长，而应用本身仍保持可用。GitHub 问题 openai/codex#25921 由用户 Jolg42 于 2026 年 6 月 2 日开启，记录了最初报告的 4.9 GB 和单日 54,504 个文件；随后四个月的评论报告了 59 GB、61 GB、100 GB、137 GB、174 GB，以及一台机器上两个 Crashpad 路径合计约 323 GB。

该问题被标记为 app、bug 和 performance，并且在源数据抓取时仍处于开启状态。核心缺陷有两个可分离的部分：一个在受影响的 macOS 版本上崩溃并循环重启的 Crashpad 处理程序，以及该崩溃写入的目录完全没有保留限制。

该错误的实际情况

Codex 桌面版附带一个 Chromium/Electron 的 browser_crashpad_handler 辅助程序。在受影响的机器上，该处理程序在启动时失败并写入自身的 minidump，然后被重新启动并再次在相同的检查中失败。每次迭代都会在 Crashpad 的 pending 队列中生成一对 .dmp 文件和 _sidecar.json 元数据文件。

用户可见的症状并不是 Codex 应用崩溃。应用保持正常功能——用户可以在同一会话中与其交互并检查文件系统——而磁盘使用量在后台悄然攀升。应用内没有任何内容显示警告。

各版本报告中的磁盘使用情况

增长规模因机器和循环未被发现的时间长短而有很大差异。

报告者 日期 应用版本 报告大小 文件数
Jolg42（作者） 2026 年 6 月 2 日 26.527.60818 单日 4.9 GB 54,504
mxggle 2026 年 6 月 7 日 — 59 GB 达到 65,535 文件限制
dionylon 2026 年 6 月 9 日 26.602.71036 58.89 GiB 738,864
guojianlan 2026 年 6 月 18 日 26.611.62324 137.32 GiB 1,786,086
libairi 2026 年 7 月 21 日 26.715.70719 约 33.4 GiB —
austinhutchison 2026 年 8 月 15 日 26.803.61601 约 100 GB 约 100 万
dewalt-1 2026 年 9 月 2 日 26.818.41509 174.6 GB 约 108 万个转储文件，超过 200 万个文件
ashtonsix 2026 年 10 月 5 日 26.930.21537 114.22 GB 1,212,428
ahmedkhan25 2026 年 10 月 17 日 26.1007.71326 两条路径合计约 323 GB 约 404 万

最初的报告测量到 27,252 个 .dmp 文件和 27,252 个 _sidecar.json 文件——精确的 1:1 配对——总计 4.9 GB。作者删除内容后，目录降至 6.4 MB 和 70 个文件，但新的配对文件立即出现，确认是活跃生成而非过时的积压。

确切的处理程序失败

多位报告者从最新的 .dmp 文件中提取了相同的致命消息。它来自 Crashpad 自身的异常处理程序服务器，而非 Codex 应用或渲染器：

[FATAL:third_party/crashpad/crashpad/handler/mac/exception_handler_server.cc:76]
Check failed: kr == KERN_SUCCESS.
mach_port_request_notification: (os/kern) invalid capability (20)

转储文件带有注释，标识崩溃进程为处理程序自身：

executable_path=/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/152.0.7977.64/Helpers/browser_crashpad_handler
--monitor-self-annotation=ptype=crashpad-handler
ptype=crashpad-handler

macOS 自身的诊断日志也证实了这一点。报告者在 ~/Library/Logs/DiagnosticReports 下发现了重复的 .ips 条目，其中 procName: browser_crashpad_handler、exception: EXC_BREAKPOINT / SIGTRAP 以及 coalitionName: com.openai.codex。

为什么循环永远不会终止

用户 ReymondAkpanya 在 2026 年 9 月 21 日的评论中提供了关于自我维持循环的最清晰解释。由于处理程序以 --monitor-self-annotation 启动，它会监控自身。序列如下：

  1. 处理程序调用 mach_port_request_notification 并收到 KERN_INVALID_CAPABILITY (20)。
  2. 它在 exception_handler_server.cc:76 处触发 CHECK 并死亡。
  3. 自我监控器写入处理程序自身的 minidump。
  4. 处理程序被重新启动，在相同的检查中失败，并返回步骤 2。

这是一个没有基本情况的循环，这就是为什么增长是完全线性的，而不是与任何应用活动相关。

该报告中的测量速率：恰好每秒一个转储文件，每个 181,552 字节，外加一个 24 字节的 _sidecar.json——大约每小时 3,600 个转储文件，每小时约 0.6 GB，或在应用运行时每天约 15 GB。在该案例中，队列达到了 240,966 个文件和 21 GB，并将一个 228 GB 的磁盘降至 0 字节可用空间。所有 240,966 个报告中的 completed/ 目录都是空的，这意味着没有任何东西会清空队列。

上游原因并非 Codex 特有

mach_port_request_notification / KERN_INVALID_CAPABILITY 失败是 Crashpad 在 macOS 上的 Mach IPC 问题，并非 Codex 独有。在 macOS Tahoe 26.3.1 上，同样的错误也被报告到其他 Chromium/Electron 应用，包括 Claude Desktop (anthropics/claude-code#37230) 和 VS Code (microsoft/vscode#282433)。

这个区别对于任何评估该错误的人来说都很重要。上游的 CHECK 失败是环境性的。无限制的磁盘消耗则不是——任何可重复的处理程序启动失败都会产生同样的失控，因为自我监控器将处理程序自身的致命 CHECK 视为可报告的崩溃。正如 ReymondAkpanya 所说，触发因素是上游的，但放大不是。

保留错误独立于崩溃循环

用户 dewalt-1 提出了最有力的论点，即这是两个独立的缺陷。2026 年 9 月 2 日，他们报告 ~/Library/Application Support/Codex/Crashpad/pending 中有 174.6 GB，而 Application Support/Codex 中所有其他内容合计为 171 MB——占该目录的 99.9%。转储文件是均匀的约 161 KB 配对，约 108 万个转储文件和超过 200 万个文件。

关键的是，那台机器没有处于紧密循环中：pending/ 的最后一次写入是在 16 小时前，并且应用在那之后一直在运行而没有添加内容。Crashpad/ 目录创建于 2026-04-05，这意味着五个月内平均每天约 1.1 GB，而不是每天 5–17 GB。

无论什么生成转储文件，都没有什么会清理它们。保留错误看起来与任何特定的崩溃循环是可分离的：即使崩溃率很低，五个月后也会达到 175 GB。对 pending/ 设置大小或年龄上限将独立于修复崩溃器来限制损害。

用户 jakehop 在 2026 年 8 月 9 日指出，Crashpad 附带了一个清理器，但在此集成中未实现：“我在其他 Electron 应用中见过这种行为，处理程序已连接但清理器未连接，如果遥测被关闭或阻止，这些日志就会在 pending 中堆积。”

受影响的路径和版本

报告中出现了两个 Crashpad 数据库路径，并且同一台机器上可能同时受影响：

  • ~/Library/Application Support/com.openai.codex/web/Crashpad/pending — 早期 Codex 桌面版使用的旧路径。
  • ~/Library/Application Support/Codex/Crashpad/pending — 统一 ChatGPT/Codex 桌面应用使用的新路径。

ahmedkhan25 于 2026 年 10 月 17 日同时测量了两者：旧路径中 180 GB / 2,251,765 个文件，新路径中 143 GB / 1,785,095 个文件，合计约 323 GB 和约 404 万个文件——约占 926 GB 磁盘的 35%。在他们发现之前，可用空间已降至 1.4 GB。

报告的应用版本从 26.527.60818（6 月）到 26.1007.71326 构建 20398（10 月），Chromium 框架版本从 148.0.7778.179 到 155.0.8059.40。报告中受影响的 macOS 版本集中在 15.x 和 26.0–26.3。

版本和平台信号

贡献者 dnakov 于 2026 年 6 月 14 日评论：“我认为这在后来的 macOS 版本中已修复。至少在 26.5 中是这样。”用户 nathanvy 于 2026 年 10 月 18 日报告在 macOS 26.6.2 上运行 codex v26.1013.40934 构建 20770 时未受影响。

这种模式——在 15.x 和 26.0–26.3 上受影响，在 26.5+ 上不受影响——与 Mach IPC 失败依赖于内核版本一致。然而，该线程也包含关于较新构建和较新路径的报告，并且 libairi 发现仅回滚应用构建没有帮助：构建 5538 (26.715.31251) 和构建 5650 都使用 Chromium 150.0.7871.124，共享相同的 Mach-O UUID，并且未签名代码区域具有相同的 SHA-256 哈希。

用户报告的有效解决方法

1. 删除待处理报告

最简单的遏制方法是直接删除 pending 目录中的文件。作者自己的 cron 条目，发布于 2026 年 6 月 20 日：

*/15 * * * * /usr/bin/find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f -delete >/dev/null 2>&1 || true

使用 crontab -e 设置，并使用 crontab -l 验证。这只会删除 pending 目录中直接包含的文件。

2. 将待处理目录设为只读

几位用户通过清空目录后移除写权限来阻止增长。ReymondAkpanya 的版本：

P=~/Library/"Application Support"/Codex/Crashpad/pending
find "$P" -type f -delete
chmod 500 "$P"

他们确认增长停止，并且没有内容溢出到 new/、completed/ 或 attachments/——整个 Crashpad 目录保持在 20K。使用 chmod 700 恢复。

dionylon 在整个数据库上使用了更强的变体，在重新创建 pending、new、completed 和 attachments 子目录后，结合了 chmod -R 555 和 chflags -R uchg。这在观察窗口内将 pending 保持在零。他们指出，即使使用 sudo，macOS 也不允许修改处理程序二进制文件本身（Operation not permitted）。

3. 将文件移到废纸篓而不是删除

用户 liuminsheng3 建议只将 Crashpad 报告桶移到废纸篓，而不是删除整个应用数据目录，并先停止处理程序：

osascript -e 'quit app "Codex"' 2>/dev/null || true
pkill -f "browser_crashpad_handler.*codex.*/Crashpad" 2>/dev/null || true

for crash in \
  "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \
  "$HOME/Library/Application Support/Codex/Crashpad"; do
  [ -d "$crash" ] || continue
  mkdir -p "$HOME/.Trash/Codex-Crashpad"
  for bucket in pending new completed attachments; do
    [ -d "$crash/$bucket" ] || continue
    find "$crash/$bucket" -mindepth 1 -maxdepth 1 -exec mv {} "$HOME/.Trash/Codex-Crashpad/" \;
  done
done

这在规模上很重要：ahmedkhan25 报告说删除数百万个小文件很慢，而重命名文件夹是即时的。its-tahir 给出了同样的建议——“将 Crashpad 文件夹移到废纸篓。即使有数百万个文件也是即时的，而 rm 删除 400 万个文件则很慢。”

4. 通过 LaunchAgent 进行有界保留

ashtonsix 安装了一个 LaunchAgent，每五分钟运行一次，使超过 24 小时的报告过期，并将每个 pending/completed 队列限制为 64 个报告组和 256 MiB。它对匹配的 UUID 转储/侧车文件进行分组，给新写入两分钟的宽限期，并跳过未知文件、符号链接以及在检查期间更改的文件。他们明确将其框定为限制保留的诊断存储，而不使数据库不可写——而不是修复崩溃的辅助程序。

无效的解决方法

libairi 在统一应用上测试了几种方法，并报告所有方法均无效：

  • 使用 --disable-breakpad 启动并不能阻止新的 Crashpad 报告。
  • 拒绝执行处理程序停止了待处理转储，但导致 macOS 反复出现“ChatGPT 意外退出”报告和弹窗。
  • 定期仅删除 Crashpad/pending 可以控制磁盘使用，但不能修复处理程序崩溃循环。

dionylon 还报告说，完全重新安装没有修复问题，并且禁用 browser@openai-bundled、禁用 chrome@openai-bundled 以及在 ~/.codex/config.toml 中设置 BROWSER_USE_AVAILABLE_BACKENDS = "" 在重启后并没有阻止转储增长。

关于只读解决方法的注意事项

用户 liuminsheng3 警告说，将 Crashpad/pending 设为只读应被视为紧急制动，而不是默认的清理路径。它可以阻止活跃的转储循环，但也会阻止 Codex 写入崩溃报告，并可能隐藏维护人员需要的信号。他们建议保持范围狭窄，并避免在 ~/Library/Application Support/Codex、~/Library/Application Support/com.openai.codex 和临时 com.openai.codex.code_sign_clone 目录上永久设置只读状态。

他们建议的顺序：退出 Codex；仅将 Crashpad 报告桶移到废纸篓；重新启动并观察 pending 是否重新增长；仅在其活跃重新填充时应用只读解决方法；并在应用或版本问题修复后撤销只读位。

如何检查您是否受影响

its-tahir 在线程中发布了一个简洁的分诊摘要。检查两个 Crashpad 路径的大小：

du -sh "$HOME/Library/Application Support/Codex/Crashpad" \
       "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" 2>/dev/null

检查现在是否正在写入转储文件——最后一分钟内大约 60 个 .dmp 文件意味着循环正在运行：

find "$HOME/Library/Application Support/Codex/Crashpad/pending" \
  -maxdepth 1 -name '*.dmp' -mmin -1 | wc -l

然后退出应用，使用 pgrep -fl browser_crashpad_handler 检查是否有残留处理程序，并将 Crashpad 文件夹移到废纸篓。

为什么不应公开共享转储文件

每位附上证据的报告者都扣留了原始 .dmp 文件。原作者表示：“我不会公开附加 minidump，因为它们可能包含内存、本地路径或私人数据。如果 OpenAI 维护人员提供安全的上传路径，我可以私下分享最新的 .dmp。”多位后来的评论者重复了同样的警告，指出转储文件可能包含内存、本地路径、提示或项目状态。元数据——计数、大小、最早和最晚时间戳、应用版本以及哪个路径仍在增长——被认为足以进行公开分诊。

Hacker News 上的社区反应

Hacker News 讨论（156 分，73 条评论）较少关注技术机制，而更多关注模式。几位评论者指出，这不是第一个具有 SSD 磨损影响的 Codex 错误；一位引用了之前一个 Codex 无限日志记录问题。

“这是第二个可能对您的 SSD 产生重大耐久性影响的 Codex 错误，尽管不如第一个严重，第一个是无限日志记录。”

其他人报告了来自相邻原因的磁盘压力，而不是 Crashpad 本身。一位评论者将他们的磁盘使用追溯到 git worktrees 在并发功能中复制构建工件，以及因达到内存限制而产生的重度 macOS 交换。另一位报告说 Codex worktrees 中留下了数千个屏幕截图和工件，以及 Windows VM 上生成了 90 GB 的不必要验证测试。该评论者补充说：“这绝对是 Codex 的问题，我从未在 Claude Code 或 Antigravity 中见过这种情况。”

另一位评论者发现 ~/.bun/install/cache/@openai 中有 11 个重复的 codex 和 codex-code-mode-host 二进制文件，每个约 300 MB。另一位报告说 .staging/marketplace 目录中有 14 GB 的小文件。

几条评论对初始报告和修复之间四个月的间隔提出了尖锐批评。一位指出 Crashpad 自身的清理器存在但未在此集成中连接。另一位观察到用户被要求解决核心产品中的错误，而不是修复它。

线程中的实用建议包括将代理框架降级到 Docker 容器，使用 DaisyDisk 等磁盘可视化工具来查找增长，以及检查 ChatGPT 应用设置中的存储部分，该部分显示已用磁盘空间。

修复需要解决什么

ReymondAkpanya 提出了两个独立的缓解措施，每个都可以防止最坏的结果：

  1. 阻止自我监控器报告处理程序自身的启动 CHECK 失败，或在 N 次连续相同转储后退避和限速。这可以打破循环，无论上游原因如何。
  2. 使用大小上限或 TTL 限制 pending/，这样静默失败的上传路径就无法填满磁盘。

任何一个都可以将这种情况从“磁盘为 0 字节”变成一行日志。

ahmedkhan25 以同样的精神添加了三个要求：对 Crashpad/pending 设置大小或计数上限并自动清理；修复处理程序崩溃循环；以及当 Codex 自身数据超过几 GB 时在应用内发出警告。

状态

在源数据抓取时，该问题仍处于开启状态，并带有 app、bug 和 performance 标签。线程中最近的报告（2026 年 10 月）描述了应用版本高达 26.1007.71326 构建 20398 以及两个 Crashpad 路径上的错误。一位贡献者评论表明较新的 macOS 版本（26.5 及以上）不受影响，一位 macOS 26.6.2 用户报告没有影响——但线程中也包含较新构建的报告，以及相邻构建之间处理程序二进制文件未更改的证据。线程中尚未确认官方修复或保留限制。

Sources