在 GitHub（GitHub）的开放人工智能（OpenAI）codex 仓库中，有编号为 25921 的问题报告称，Codex 桌面版（Codex Desktop）正在持续不断地生成 Crashpad（Crashpad）的待处理转储文件（pending dumps），这些转储文件的体积增长没有任何限制，其占用空间持续增长，每天至少增加 5GB，增长量没有上限。

摘要

Codex Desktop 会持续在以下路径添加成对的 .dmp 和 _sidecar.json 文件：

~/Library/Application Support/com.openai.codex/web/Crashpad/pending

在我的机器上，这个目录一天内增长到 4.9G，包含 54,504 个文件。调查期间文件数还在继续增加，所以这是 Crashpad 在持续生成待处理 dump，而不是一次性的历史遗留文件。

Codex Desktop 应用在发生这种情况时仍然可用。我可以使用应用、检查文件系统，并在同一个运行中的会话里与 GitHub 交互。因此用户可见的问题并不是 Codex 完全崩溃或无法启动，而是 Crashpad 在后台持续生成待处理的 dump/sidecar 对，而应用仍可用，导致本地磁盘占用无上限增长。

我没有公开附上 minidump，因为它们可能包含内存、本地路径或私人数据。如果 OpenAI 维护者提供安全的上传途径，我可以私下分享最新的 .dmp 文件。

环境

• 产品：macOS 上的 Codex Desktop 应用
• Codex 应用版本：26.527.60818
• CFBundleVersion：3437
• 从活动进程观察到的 Crashpad/Electron 标注：prod=Codex_Mac，ver=148.0.7778.179
• macOS：26.3.1 (25D771280a)
• 架构：arm64

观察到的证据

Crashpad 待处理目录为：~/Library/Application Support/com.openai.codex/web/Crashpad/pending。

最新测量结果：该目录 4.9G，总计 54,504 个文件，其中 27,252 个 .dmp 文件、27,252 个 _sidecar.json 文件。

抽样待处理文件的时间范围：最旧为 2026-06-02 13:31:21 CEST，最新为 2026-06-02 21:08:24 CEST。

调查期间文件数从 53,444 增加到 54,064，再到 54,504，说明队列仍在增长。

我还观察到两个 Codex browser_crashpad_handler 进程自 Sat May 30 11:47:50 2026 起在 PPID=1 下运行，使用同一个 Crashpad 数据库。进程命令为 /Applications/Codex.app/.../Helpers/browser_crashpad_handler，参数包括 --database=~/Library/Application Support/com.openai.codex/web/Crashpad、--annotation=plat=OS X、--annotation=prod=Codex_Mac、--annotation=ver=148.0.7778.179。

本地应用仍可用于检查和报告问题，所以可见问题不只是普通的前台应用崩溃。看起来是 Crashpad 或被监控的辅助进程在反复生成待处理 dump，且没有限制、上传/处理清理或轮转。

预期行为

崩溃报告应当是有上限的、被上传/处理/轮转的，或者在应用仍可用时不应持续生成。

实际行为

待处理的 Crashpad 报告快速累积，占用数 GB 本地磁盘空间。

用于收集证据的命令

他先后运行了 du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" 查看目录大小，用 find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f | wc -l 统计文件数，再用 find 配合 sed、sort、uniq -c 按扩展名统计数量，用 /usr/libexec/PlistBuddy 读取 /Applications/Codex.app/Contents/Info.plist 中的 CFBundleShortVersionString 和 CFBundleVersion，用 sw_vers 和 uname -m 查看系统与架构，最后用 ps ax -o pid,ppid,lstart,command 过滤 browser_crashpad_handler 和 com.openai.codex/web/Crashpad 相关进程（并 grep -v grep 排除自身）。

相关问题

这可能与其他 Codex Desktop 辅助/进程清理报告有关：

• Codex App update left old crashpad helper; relaunch could no-op until clean restart#25259：更新/重启后残留 Crashpad 辅助进程。
• Codex App UI freezes: worker crashes, massive git/worktree errors, and concurrent orphaned app-server processes#11090：孤儿 Codex 进程和 UI 冻结。
• Can't open app in Tahoe 26.2 (25C56)#10627：之前的 Crashpad/macOS 启动报告。

活动记录

github-actions 于 2026 年 6 月 2 日添加了 bug、app、performance 标签。

Jolg42 于 2026 年 6 月 2 日评论

Jolg42 更新说：提交 issue 后，他清空了 Crashpad pending 目录里的文件。清理前为 4.9G、54,504 个文件；清理操作是删除 ~/Library/Application Support/com.openai.codex/web/Crashpad/pending 下的文件；清理后立即变为 6.4M、70 个文件，其中 35 个 .dmp 和 35 个 _sidecar.json。因此，大部分磁盘占用可以通过删除待处理报告来回收，但清理后立刻又出现了新的成对 dump/sidecar 文件。这支持了之前的观察：Crashpad dump 生成仍处于活跃状态，而不只是陈旧的历史积压。他没有公开附上任何 .dmp 文件。

mxggle 于 2026 年 6 月 7 日评论

我这里也一样，达到了 59GB🫠。即使已经碰到 65535 的文件系统上限，后台进程仍在不停地尝试 dump 更多文件。

dionylon 于 2026 年 6 月 9 日评论

我在 macOS 上使用更新的 Codex Desktop 构建也遇到相同问题，并补充了更多诊断细节。

环境

• 产品：macOS 上的 Codex Desktop 应用
• Codex 应用版本：26.602.71036
• CFBundleVersion：3685
• 从 dump 中观察到的 Framework/Crashpad 标注：ver=149.0.7827.54
• 架构：arm64
• Crashpad 数据库路径：~/Library/Application Support/com.openai.codex/web/Crashpad

观察到的影响

待处理目录增长到约 61G。清理前的计数：文件 738,864 个、.dmp 文件 369,431 个、_sidecar.json 文件 369,433 个、字节数 63,233,668,274、约 58.89 GiB；最近 24 小时 98,218 个文件，最近 7 天 573,480 个；最旧 2026-06-01 10:52:52，最新 2026-06-09 10:00:26。

清理/重装/重启后，目录继续以大约每秒一个崩溃报告的速度增长：10:28:46 时 files=142 MiB=11.63，10:28:51 时 files=152 MiB=12.44，10:28:56 时 files=162 MiB=13.26，10:29:01 时 files=172 MiB=14.08，10:29:06 时 files=182 MiB=14.89。

关键诊断细节

最新的 .dmp 文件里包含来自 browser_crashpad_handler 自身的 FATAL 信息：

browser_crashpad_handler、Codex_Mac、crashpad-handler；[0609/103121.674299: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/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/149.0.7827.54/Helpers/browser_crashpad_handler；--database=/Users/<user>/Library/Application Support/com.openai.codex/web/Crashpad；--annotation=prod=Codex_Mac。

所以看起来是 browser_crashpad_handler 自己崩溃/重启循环，并为自身写入成对的 .dmp / _sidecar.json 文件。

系统诊断日志也显示重复的 browser_crashpad_handler 崩溃：procName: browser_crashpad_handler；procPath: /Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/149.0.7827.54/Helpers/browser_crashpad_handler；coalitionName: com.openai.codex；exception: EXC_BREAKPOINT / SIGTRAP。

相关行为

这台机器上的应用内浏览器 / Browser Use 之前曾变为不可用。调查期间，Codex 日志反复出现 Browser Use / IAB 生命周期条目，且在 Crashpad 持续生成 dump 前不久出现了 browser_use_availability_resolved available=true。这可能是触发因素，也可能不是，但问题看起来与 Codex Desktop 的浏览器/Chromium/Crashpad 路径有关。重装没有修复。禁用 browser@openai-bundled、禁用 chrome@openai-bundled，以及在 ~/.codex/config.toml 中设置 BROWSER_USE_AVAILABLE_BACKENDS = ""，重启后也都没能阻止 dump 增长。

停止磁盘增长的临时解决方法

由于 macOS 即使使用 sudo 也不允许修改 /Applications/Codex.app/.../browser_crashpad_handler（Operation not permitted），他把用户级 Crashpad 数据库设为只读且不可变来绕过：先 pkill -f "browser_crashpad_handler.*com.openai.codex/web/Crashpad"，再对 Crashpad 目录执行 chflags -R nouchg、chmod -R u+w，删除 pending、new、completed、attachments 目录后重建这些目录，接着 chmod -R 555 并用 chflags -R uchg 对整个 Crashpad 目录加锁（其中 crash 变量为 ~/Library/Application Support/com.openai.codex/web/Crashpad）。

之后，在观察窗口内 pending 保持为零：10:40:12 到 10:40:47 多次检查均为 files=0 MiB=0.0。这只是阻止磁盘增长的临时方法，不是真正的修复，因为它实际上阻止了 Codex 写入 Crashpad 报告。

Cuimc 于 2026 年 6 月 9 日评论

我也是，今天刚清理了 22G。

Jolg42 于 2026 年 6 月 9 日修改了标题

他把标题从「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」。

changjonathanc 于 2026 年 6 月 13 日评论

在版本 26.601.10930 上也遇到相同问题，并 @ 了 dnakov。

dnakov 于 2026 年 6 月 14 日评论（贡献者）

我认为后续 macOS 版本已经修复了这个问题，至少在 26.5 上是好的。

ai-poet 于 2026 年 6 月 17 日评论

我也遇到了完全一样的问题。天哪，怪不得我的 Mac 存储空间一直满。Codex Desktop 难道就是 OpenAI 用 vibe coding 堆出来的一堆垃圾代码吗？

jordanade 于 2026 年 6 月 17 日评论

Claude 和 Codex 都完全不尊重用户的机器。真是见鬼了。

cyfung1031 于 2026 年 6 月 18 日评论

每个 json 只有 2 bytes 加上 150KB，但更严重的是背后还有崩溃报告在 /System/Library/Caches/com.apple.coresymbolicationd/data 里持续生成。

用这个脚本检查你的 macOS：脚本 recent-files.sh 按指定目录和小时数列出最近修改的文件，支持 Linux GNU find、macOS Spotlight（mdfind）或 FORCE_SCAN=1 全盘扫描，按修改时间倒序排列，并分页显示文件大小、添加时间、修改时间和路径。

查看并清理崩溃报告的脚本：针对 /System/Library/Caches/com.apple.coresymbolicationd，可停止 coresymbolicationd 进程并删除缓存目录内容（需输入 CLEAN 确认），macOS 会在需要时重建缓存。删除之后，也可以尝试删除 ~/Library/Saved Application State/com.openai.codex.savedState 来重置 Codex。

guojianlan 于 2026 年 6 月 18 日评论

我碰到的似乎是同一个 Crashpad 待处理 dump 增长问题，但规模大得多。

环境

• 产品：macOS 上的 Codex Desktop 应用
• Codex 应用版本：26.611.62324
• CFBundleVersion：4028
• macOS：15.6 (24G84)
• 架构：arm64
• 从活动进程路径观察到的当前辅助/Crashpad 标注：Electron/Chromium 辅助 149.0.7827.115

观察到的磁盘占用

大幅增长出现在旧版应用数据路径下：~/Library/Application Support/com.openai.codex/web/Crashpad/pending。

清理前，该目录包含：1,786,086 个条目、893,043 个 .dmp 文件、893,043 个 _sidecar.json 文件、总计 147,440,897,945 字节、137.32 GiB，其中 .dmp 文件占 137.31 GiB。文件时间范围：最旧 2026-06-01 11:55:53，最新 2026-06-18 14:16:58。每日分布中多天超过 13 GiB，例如 2026-06-06 为 13.17 GiB、2026-06-07 为 13.18 GiB、2026-06-08 为 13.18 GiB、2026-06-12 为 13.14 GiB、2026-06-13 为 13.17 GiB 等。最大的 dump 文件仍然相对较小，如 782,272 字节、739,984 字节、705,456 字节。所以磁盘增长是由数十万个小的崩溃 dump 造成的，而不是少数几个大文件。

清理结果

删除待处理文件后，旧路径已为空：count=0、total_mib=0.00。当前运行的 Codex 应用似乎使用不同的应用数据路径：~/Library/Application Support/Codex/Crashpad。那里当前很小：Codex 目录 223M，Crashpad 目录 20K，pending 目录 16K，pending count=4。这个路径差异可能很关键：无上限增长发生在 com.openai.codex/web/Crashpad，而当前运行的应用使用 Codex/Crashpad。我没有公开附上 .dmp 文件，因为它们可能包含私人内存、路径或本地状态；如果需要，我可以通过维护者提供的安全上传途径分享 dump 或额外元数据。

liuminsheng3 于 2026 年 6 月 19 日评论

对于仍想区分「旧积压」和「活跃 dump 循环」的人，建议在删除更广泛的应用状态前，分别测量两个 Codex 应用数据路径：~/Library/Application Support/com.openai.codex/web/Crashpad 和 ~/Library/Application Support/Codex/Crashpad。他给出的检查方法是对每个 Crashpad 目录执行 du -sh 查看大小，用 find "$crash/pending" -maxdepth 1 -type f | wc -l 统计文件数，分别统计 .dmp 和 *_sidecar.json 的数量，并用 stat 配合 sort 取出最旧和最新的时间戳。

清理时，除非打算完整重置本地状态，否则不要删除整个 Application Support/Codex 目录。较窄的恢复路径是：1. 退出 Codex；2. 停止仍在写入该 Crashpad 数据库的任何 Codex Crashpad handler；3. 只把 Crashpad 报告桶（如 pending、new、completed、attachments）移到废纸篓；4. 重启 Codex 并观察几分钟 pending 计数。示例的只移入废纸篓版本会先 osascript -e 'quit app "Codex"'，再 pkill -f "browser_crashpad_handler.*codex.*/Crashpad"，然后对每个 Crashpad 目录在 ~/.Trash/Codex-Crashpad 下创建目录，并把各报告桶中的内容 mv 进去。

他不会公开附上 .dmp 文件，因为它们可能包含内存、本地路径、提示词或项目状态。公开分类通常只需计数、大小、最旧/最新时间戳、应用版本以及哪个路径仍在增长等元数据即可。他维护着一个本地优先的存储清理/检查清单项目 SafeDisk，并写了关于此次 Crashpad 清理边界的说明：https://www.getsafedisks.com/codex-crashpad-pending-dumps-disk-space?utmsource=github&utmmedium=issue-comment&utmcampaign=codex-crashpad-disk-space&utmterm=codex-crashpad-pending-dumps&utm_content=openai-codex-25921 。如果有人想在删除应用状态前获得私下二次确认，该页面现在在只读检查后有一个单页 Deep Cleanup 请求表单。

Jolg42 于 2026 年 6 月 20 日评论

我的 macOS 临时解决方法：每 15 分钟清空一次 Codex 的待处理 Crashpad 报告，以避免本地堆积。crontab 行是：

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

在 macOS 上用 crontab -e 添加该行，保存后用 crontab -l 验证。它只删除 ~/Library/Application Support/com.openai.codex/web/Crashpad/pending 目录内直接的文件。

Jolg42 于 2026 年 6 月 20 日再次评论

如果你也遇到这个问题，这个用 vibe coding 写出来的应用还有另一种浪费磁盘空间的方式，参见 #25667（评论）。

cyfung1031 于 2026 年 6 月 21 日评论

我找到一个似乎很有效的方法：按 Jolg42 提到的方式清理文件夹，然后把它设为只读。我测试了几个小时，现在 Codex 不能再往这个文件夹写任何垃圾了。

只处理 Crashpad/pending/ 的脚本会删除该目录下所有文件并将其权限改为只读（chmod -R a-w）。同时处理 Crashpad/pending/ 和 com.openai.codex.code_sign_clone 的脚本，还会清理 /private/var/folders 下名为 com.openai.codex.code_sign_clone 的目录：先 chmod -R u+w，删除其中内容，再设为只读。

liuminsheng3 于 2026 年 6 月 22 日评论

对上述 chmod / 只读解决方法的一个提醒：我会把它当作紧急刹车，而不是默认的清理路径。只把 Crashpad/pending 设为只读可以阻止活跃的 dump 循环，但也会阻止 Codex 写入崩溃报告，并可能隐藏维护者需要的信号。范围要窄，不要把这些更宽的路径永久设为只读：~/Library/Application Support/Codex、~/Library/Application Support/com.openai.codex、临时 com.openai.codex.code_sign_clone 目录。

更安全的顺序是：1. 退出 Codex；2. 只把 Crashpad 报告桶（如 pending、new、completed、attachments）移到废纸篓；3. 重启 Codex 并观察 pending 是否再次开始增长；4. 只有在它确实在重新填充、且你需要立刻停止磁盘损失时，才使用只读解决方法；5. 在应用/版本问题修复后撤销只读位。他更新了清单，加入了更窄的警告和一个小的回滚片段：https://www.getsafedisks.com/codex-crashpad-pending-dumps-disk-space?utmsource=github&utmmedium=followup&utmcampaign=first-paid-cleanup&utmterm=codex-crashpad-pending-dumps-disk-space&utm_content=readonly-safety-followup 。

Eseperio 于 2026 年 7 月 16 日评论

这是一个严重问题，正在迅速损坏那些内存不可更换的电脑的硬件。必须尽快修复。

libairi 于 2026 年 7 月 21 日评论

在当前的统一 ChatGPT/Codex desktop 应用中仍然可复现，且使用更新的 Crashpad 数据库路径。

环境

• 应用：ChatGPT 统一桌面应用（com.openai.codex）
• 应用版本：26.715.70719
• 构建：5650
• macOS：15.7.4（24G517）
• 架构：Apple Silicon / arm64
• Chromium framework：150.0.7871.124
• Crashpad 数据库：~/Library/Application Support/Codex/Crashpad

影响

Crashpad/pending 达到约 33.4 GiB，其中最近三天生成了约 23.3 GiB。删除待处理报告回收了磁盘空间，但立刻又开始出现新的成对 dump/sidecar。当 browser_crashpad_handler 反复崩溃和重启时，主 ChatGPT 窗口可以仍然存活。macOS 在 2026-07-20 保留了至少 50 个 handler 崩溃报告，2026-07-21 保留了 43 个；实际的 Crashpad 待处理 dump 数量要高得多。

确切的 handler 失败

[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)。

macOS .ips 报告显示：procName: browser_crashpad_handler；responsibleProc: ChatGPT；exception: EXC_BREAKPOINT / SIGTRAP；procPath: /Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/150.0.7871.124/Helpers/browser_crashpad_handler。

这台机器上保留的最早报告是 2026-07-20 08:17:09 +0800，早于 build 5650 安装到该机器的时间；其 handler UUID 是 4C4C44FF-5555-3144-A167-DF0A5F297DB2。他还下载了官方 build 5538（26.715.31251）并和 build 5650 对比：两者都使用 Chromium 150.0.7871.124，Mach-O UUID 相同，且未签名代码区的 SHA-256 哈希完全一致。因此仅回滚到 build 5538 也不大可能避免该失败。

测试过的解决方法

• 用 --disable-breakpad 启动：没能阻止新的 Crashpad 报告。
• 拒绝执行 handler：停止了待处理 dump，但导致反复出现 macOS「ChatGPT quit unexpectedly」报告/弹窗，所以不可行。
• 周期性只删除 Crashpad/pending：能控制磁盘占用，但不能修复 handler 崩溃循环。

没有附上 .dmp 文件，因为它可能包含私人进程内存；如果需要，他可以提供脱敏元数据或使用维护者提供的私下上传渠道。桌面应用能否修复 handler 启动/自我监控失败、支持崩溃报告退出选项，或对 pending dump 强制执行严格保留/大小上限？

jakehop 于 2026 年 8 月 9 日评论

这里也遇到同样问题。奇怪的是，Crashpad 本身就带 pruner，但这里没有实现。他在其他 Electron 应用中也见过这种行为：handler 接好了但 pruner 没接，如果遥测被关闭或拦截，这些日志就只会堆在 pending 里。

austinhutchison 于 2026 年 8 月 15 日评论

在当前的统一 ChatGPT/Codex desktop 应用上看到同样的 Crashpad 待处理报告增长。

环境：应用为带 Codex 的 ChatGPT 桌面应用，版本 26.803.61601，构建 6396，macOS 26.3.1 (25D771280a)，架构 arm64。受影响的路径是 ~/Library/Application Support/Codex/Crashpad/pending。该目录增长到约 100 GB、大约一百万个文件，文件是 Crashpad 待处理报告（包括 .dmp 和 sidecar 元数据）。目录增长时应用仍可用。这看起来是较新的 Codex/Crashpad 路径，而不是旧的 ~/Library/Application Support/com.openai.codex/web/Crashpad/pending。删除或移走 Crashpad/pending 内容可以回收磁盘空间，但他尚未确认清理后目录是否会重新增长。有人能澄清「后续 macOS 版本，至少 26.5」修复此问题的说法是否指已知的 macOS 修复吗？如果是，macOS 26.5 是预期能防止 Crashpad handler 失败，还是也需要 Codex 应用更新？他没有附上 dump 文件，因为可能包含进程内存、本地路径或其他私人数据；可以提供脱敏的计数、时间戳或日志来帮助诊断。

lske837 于 2026 年 9 月 1 日评论

我在 macOS 上看到似乎是同一类问题，不过我的 Crashpad 数据库路径不同：~/Library/Application Support/Codex/Crashpad/pending。我的 Codex Desktop 版本是 26.825.51511，活动 Codex 辅助进程使用 --user-data-dir=/Users/xxx/Library/Application Support/Codex 和 --database=/Users/xxx/Library/Application Support/Codex/Crashpad。pending 目录包含本 issue 描述的同样成对的 .dmp 和 _sidecar.json 文件；部分抽样报告可追溯到 2026 年 6 月，其他则是 8 月底。

目录已经大到连枚举都很慢：一次受限目录读取在 8 秒内没有完成，一次受限扫描只处理了 118 个条目（约 10 MB）就超时，所以这不是正常的小规模崩溃报告队列。它也似乎仍然是活跃的，而不只是包含旧遗留物：在一次 30 秒只读观察中，pending 目录修改时间从 2026-09-01 15:51:03 +0800 前进到了 2026-09-01 15:51:34 +0800。另外，发生这种情况时他还观察到一个名为 ReportClash 的进程持续占用 CPU；他还不知道它是 Codex 子/辅助进程还是无关进程，所以只作为相关性报告。

dewalt-1 于 2026 年 9 月 2 日评论

当前构建上仍然存在，补充一个与 #36982 中 browser_crashpad_handler SIGTRAP 循环特征不同的数据点。

环境：ChatGPT.app 26.818.41509（构建 6962），bundle com.openai.codex，Codex Framework（Chromium）151.0.7922.170，macOS 15.6.1。~/Library/Application Support/Codex/Crashpad/pending 为 174.6 GB，而 Application Support/Codex 中其他所有内容加起来只有 171 MB——占该目录的 99.9%。文件是统一的约 161 KB .dmp 加 _sidecar.json（{"capture_kind":"crash"}）对，所以约 1.08M 个 dump、超过 200 万个文件。目录的链接数已在 65535 饱和，目录项本身为 65 MB。

与 #36982 的不同点：~/Library/Logs/DiagnosticReports 中没有 browser_crashpad_handler-*.ips（有 30 个报告，但都不是 handler 的）。不在紧密循环中：pending/ 最后一次写入是 16 小时前，此后应用一直在运行但没有再新增。dump 标注引用 Utility 和扩展进程类型。Crashpad/ 创建于 2026-04-05，所以平均每天约 1.1 GB，而不是每天 5–17 GB。

无论是什么生成了这些 dump，都没有东西清理它们。保留 bug 看起来可以与任何特定崩溃循环分离：即使崩溃率很低，五个月下来也会达到 175 GB。对 pending/ 设置大小或时间上限，可以独立于修复崩溃者来限制损害。

ReymondAkpanya 于 2026 年 9 月 21 日评论

在更新的构建上仍然存在，我认为我能补上缺失的一环：为什么循环会自我维持。

环境

• Codex/ChatGPT.app 26.831.21537，Codex Framework（Chromium）152.0.7977.64
• macOS Tahoe 26.3.1（25D771280a），Apple Silicon

这些 dump 是崩溃处理程序自身的转储

Crashpad/pending 中的每个 .dmp 都是 browser_crashpad_handler 的 minidump，而不是应用或渲染进程的。每个都包含相同的致命错误：[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。

因为 handler 是以 --monitor-self-annotation 启动的，它会监控自己。顺序是：1. handler 调用 mach_port_request_notification，得到 KERN_INVALID_CAPABILITY (20)；2. 在 exception_handler_server.cc:76 触发 CHECK 并死亡；3. 自我监控写入该 handler 自身的 minidump；4. handler 被重启，相同的检查再次失败，回到第 2 步。这是一个没有终止条件的循环，所以增长是完全线性的，而不是与任何应用活动相关。

实测速率

精确为每秒 1 个 dump，每个 181,552 字节，外加一个 24 字节的 _sidecar.json：约 3,600 dump/小时 ≈ 0.6 GB/小时；应用运行时 ≈ 15 GB/天。他的情况达到了 240,966 个文件 / 21 GB，并把一块 228 GB 的磁盘吃到剩余 0 字节——连无关工具都无法再创建文件。全部 240,966 个报告中 completed/ 都是空的，所以没有任何东西被排空：上传从未成功，且 pending/ 没有上限或 TTL。

macOS 在 ~/Library/Logs/DiagnosticReports 下独立记录了 387 个同一辅助程序的 .ips 报告，最早的一个日期比他注意到问题早一周。在磁盘写满之前完全没有用户可见的信号。

触发在上游，放大不在

mach_port_request_notification / KERN_INVALID_CAPABILITY 失败并不是这个应用特有的——在 Tahoe 26.3.1 上，其他 Chromium/Electron 应用也报告了完全相同的错误：Claude Desktop 在 macOS Tahoe 26.3.1 上崩溃——Crashpad machportrequest_notification 失败（anthropics/claude-code#37230）；macOS 上集成终端在运行段错误程序后永久冻结——Crashpad 致命错误杀死 PTY host（microsoft/vscode#282433）。所以 CHECK 失败本身是 Crashpad/Tahoe Mach IPC 问题。但无上限的磁盘消耗与之无关：任何可重复的 handler 启动失败都会产生同样的失控，因为自我监控把 handler 自身致命的 CHECK 当作可报告的崩溃。

两种独立的缓解措施

1. 不要让自我监控报告 handler 自身启动时的 CHECK 失败——或者在连续 N 次相同 dump 后回退/限流。仅这一项就能打破循环，无论上游原因是什么。
2. 给 pending/ 设限，用大小上限或 TTL，使静默失败的上传路径无法填满磁盘。

任一项都能把这件事从「磁盘 0 字节」变成一行日志。

临时解决方法

清空 pending/ 然后移除该目录的写权限，可立刻停止磁盘增长（handler 仍在重试，但无法再写入）：对 P=~/Library/"Application Support"/Codex/Crashpad/pending 执行 find "$P" -type f -delete，再 chmod 500 "$P"。已确认增长停止，且没有任何东西溢出到 new/、completed/ 或 attachments/——整个 Crashpad 目录保持在 20K。用 chmod 700 可逆转。

ashtonsix 于 2026 年 10 月 5 日评论

补充一个 2026-10-05 在 macOS 26.0.1（25A362）、arm64 上的实测数据点。清理期间从 ~/Library/Application Support/Codex/Crashpad/pending 删除了 1,212,428 个文件：逻辑字节 110,728,502,872 / 分配字节 114,221,113,344（114.22 GB）。文件 mtime 范围从 2026-07-27 到 2026-10-04。dump 头时间戳直方图显示仅 2026-08-27 一天就有 85,720 个 dump。这个积压是导致一块 500 GB 磁盘几乎写满的主要原因。

他在删除前解析了十个保留的 minidump 样本。十个都指明了同一个主模块：/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/151.0.7922.76/Helpers/browser_crashpad_handler。每个抽样 dump 都是 182,624 字节，并识别为 ARM64。这佐证了这里关于崩溃处理程序自身被 dump 的报告，尽管样本不能证明每个报告都有相同原因。

当前安装的应用是 26.930.21537（构建 12776），framework 154.0.8037.93。在今天的清理期间，待处理队列保持为空，而应用仍可用。他报告的是历史积压，并不声称当前构建正在活跃复现该循环，也不声称底层 bug 已修复。

为了本地遏制，他安装了一个每五分钟运行一次的 LaunchAgent：删除超过 24 小时的报告，并额外把每个 pending/completed 队列上限设为 64 个报告组和 256 MiB。它会按 UUID 分组匹配的 dump/sidecar 文件，给新写入两分钟宽限期，跳过未知文件、符号链接以及在检查期间发生变化的文件。这在不使数据库不可写的情况下限制了保留的诊断存储，但不能修复崩溃的辅助程序。内置保留/大小上限本可以独立于 handler 失败来防止这种程度的磁盘耗尽。没有附上原始 minidump。

ahmedkhan25 于 2026 年 10 月 17 日评论

当前构建上仍然发生，而且规模大得多。测量时间为 2026-10-15 到 2026-10-17。

环境

• ChatGPT.app 26.1007.71326（构建 20398），Codex Framework（Chromium）155.0.8059.40
• macOS 15.7.4，Apple Silicon（arm64）

发现

| 文件夹 | 大小 | 文件数 | | --- | --- | --- | | ~/Library/Application Support/com.openai.codex/web/Crashpad | 180 GB | 2,251,765 | | ~/Library/Application Support/Codex/Crashpad（几乎都在 pending/） | 143 GB | 1,785,095 | | 总计 | 约 323 GB | 约 404 万 |

这大约占一块 926 GB 磁盘的 35%。在他发现之前可用空间已降到 1.4 GB。应用里没有任何警告。他只是通过对 ~/Library 运行 du 才发现的。应用全程仍能工作，正如这里其他人报告的那样。所以 dump 在后台静默堆积，没有上限。

清理

在应用仍运行时，他重命名了两个 Crashpad 文件夹并删除了重命名后的副本。可用空间在几分钟内从 1.4 GB 回到 50+ GB，删除仍在继续（数百万个小文件）。

诉求

1. 给 Crashpad/pending 设置大小或数量上限，并自动清理（参见 Add storage limits and automatic cleanup for Codex-generated data#51361）。
2. 停止产生这些 dump 的 handler 崩溃循环（[app][macOS][26.727.51351] browsercrashpadhandler SIGTRAPs 2ms after launch, launchd respawns it, Crashpad/pending fills disk at ~17GB/day#36982）。
3. 当应用自身数据超过几 GB 时，在应用内显示警告。

相关：#36982、#39875、#51739、#52194、#51361。

讨论气氛以嘲讽和吐槽为主，多数人指责 Codex 和 OpenAI 的生成代码是低质量 AI 劣质代码，连吃掉数百 GB 磁盘的低级缺陷都长期不修。分歧主轴是：一方认为这是 Codex 自身产生大量垃圾文件、竞品没有的专属缺陷；另一方则指出部分压力来自 git worktree、交换空间、容器缺失等环境与工作流因素，可通过压缩、归档、限制并发缓解。

认为 Codex 吃磁盘是 OpenAI 的 AI 劣质代码与长期不修的缺陷

• 多人在自己项目或 GitHub issue 中遇到 Codex 产生并留存海量中间产物（截图、验证测试、日志等），甚至吃满 90GB 到 330GB，且不会自行清理；有人强调同样用法在 Claude Code、Antigravity 中并未出现，说明问题出在 Codex 本身。正常流程下 Codex 也会写数 GB 日志，而 OpenAI 似乎几个月来都觉得可以接受，这被不少人视为“AI 劣质代码”和工程敷衍；还有人担忧，若氛围编程得势，这种臃肿和缺陷会蔓延到软件栈每一层，整套系统都会崩溃。（认可度：较多人） > 这看起来是个缺陷，但即便正常流程 Codex 也会产生数 GB 日志，而 OpenAI 似乎几个月来都觉得可以接受。（@jbellis）

认为 OpenAI 超级智能叙事与低级缺陷形成反差

• 有人用反讽表达社区情绪：既然 OpenAI 的超级智能能解决 Navier-Stokes，却修不好一个吃掉 Mac 330GB 磁盘的愚蠢缺陷，连 GitHub issue 都不好好处理；这条玩笑代表了部分用户对 OpenAI 重宣传、轻运维的不满。（认可度：少数人） > 既然你们的超级智能能解 Navier-Stokes，为什么修不好这个吃掉我 Mac 330GB 的愚蠢缺陷？拜托去好好处理 GitHub issue 吧。（@AIorNot）

认为部分磁盘压力来自 git worktree、交换空间与未隔离的工作流

• 少数人提醒，agent 造成的磁盘压力并不都等同于 Codex 写垃圾的缺陷：自己在所有工作中都用 git worktree，会在每个 worktree 里重复生成构建产物，只能靠限制并发特性数量缓解；更隐蔽的是内存吃紧后 macOS 大量使用交换空间，而交换空间写盘后系统无法主动回收，只能重启释放，频繁发生会迅速吃掉空间。把 agent 关进 Docker 容器、限制并发、必要时重启，是这类看法的实际对策。（认可度：少数人） > 每个 git worktree 都会重复产生构建产物，而 Mac 一旦大量使用交换空间，写盘空间就无法回收，只能重启。（@glenngillen）

有价值的补充

• 文件系统压缩可缓解占用：可用 ZFS 做文件系统级压缩；但注意 Btrfs 在并发 Rust 构建时有严重争用问题，反而不适合这种场景。（@jbellis）
• 归档旧会话能减少堆积：可用 sessionwiki 归档历史 session，作者已集成进自己的 control plane（BrokkAi/mjolnir）。（@jbellis）
• 检查 Codex 二进制缓存：在 ~/.bun/install/cache/@openai 目录里可能出现多个 Codex 与 codex-code-mode-host 二进制副本，每个约 300MB，11 个副本就会占掉数 GB。（@AgharaShyam）
• 排查占用可用工具或设置：ChatGPT 应用设置内有 storage 区块显示磁盘使用；也有人用 DaisyDisk 等可视化工具定位大文件。（@piskov、@aaronbrethorst）