Codex崩溃日志323GB：Bug从6月拖至今

你的Mac硬盘还剩多少空间？有位用户发现答案时，只剩1.4 GB。

10月17日，一名Mac用户在Codex的GitHub issue里贴出一张表：两个崩溃报告文件夹，约400万个文件，合计约323 GB。他写道，这占了926 GB硬盘的约35%，"找到它之前，可用空间已经掉到1.4 GB"。

这个issue从6月2日就开着，标题把Bug说得很直白：Codex桌面端持续生成Crashpad待上传转储，无上限增长，每天至少+5GB。

数字一路往上走

这些数字全部来自issue跟踪器和OpenAI论坛里的用户，没有一个是OpenAI自己测的。

• 6月2日的原始报告：一天内4.9 GB、54504个文件
• issue #36982（应用版本26.727.51351）：速率约17GB/天
• issue #47466（9月23日，macOS 15.2）：文件夹约511 GB，应用开着时约每秒产生一个160 KB左右的minidump
• issue #51361（10月6日）：130.53 GiB，剩余可用空间约821 MiB，临时文件开始报"no space left on device"
• issue #52194（10月8日）：约168 GB、约197万个文件
• 10月16日一条论坛帖：估计约230 GB

10月17日那条评论标注了自己的构建版本：ChatGPT.app 26.1007.71326。

麻烦的地方在于，应用本身照常能用。最早的报告者就提到它一直可用，所以这个文件夹能悄悄长上几周，直到有人去看一眼。

为什么这个文件夹永远清不空

Crashpad是Chromium项目的崩溃报告器，官方描述是"用于捕获、存储和传输事后崩溃报告的库"。它的数据库里存的是"待上传的崩溃转储"，也就是pending文件夹里的那些文件。

目前最主要的解释来自用户，不是OpenAI。在#25921里，一名报告者发现每个转储都来自崩溃处理器本身——browser_crashpad_handler，好几个人引用了同一个启动失败：调用mach_port_request_notification返回"(os/kern) invalid capability (20)"，一个检查以Check failed: kr == KERN_SUCCESS失败，进程随即死掉。它被重启，再次失败，再写一个转储。#36982的标题把这事总结成一句：处理器"启动2毫秒后SIGTRAP，launchd把它重新拉起来"。#25921里还有评论说，在macOS Tahoe 26.3.1上的其他Chromium和Electron应用里也见到同样的错误。

另一半问题在于没人裁剪这个文件夹。Crashpad的设计文档写着"数据库存储可配置数量的崩溃转储，上限为可配置的最大聚合大小"。#25921里有评论说，应用没有用上Crashpad的裁剪器。#51361请求OpenAI默认开启存储上限和清理，这个issue至今开着，没有指派任何人。

修了吗？部分，也许

10月6日，一位贡献者在#47466里写道："这看起来是旧版Mac内核的问题。"同一条评论里还有一句："修复已经合并，很快会发布。"issue当天被关闭。

10月7日，有用户追问哪个已发布的构建包含这个修复、会不会清理已经堆成山的队列。那个帖子里没有出现回答。

更早的6月14日，一位贡献者在#25921里写过："我认为这在后来的macOS版本里已经修复，至少在26.5里是。"但后来的报告者跑在macOS 26.0到26.3上，仍然看到增长；#47466那份报告来自macOS 15.2。

10月17日这条报告跑在macOS 15.7.4上。那个构建是否带上了10月6日的修复，帖子里没说。#25921仍然开着。

#52194还提供了一个细节：报告者发现两个旧框架版本的处理器进程仍在运行，尽管那个版本已经不在磁盘上。杀掉进程没用，重启Mac才让循环停下来。

先查一下自己的Mac

issue里列了两个位置，一个旧的、一个新的，都用du量一下：

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

如果结果是GB级，说明转储在堆积。想知道它是否还在长，用find数文件，应用开着，隔一分钟量两次。如果大的是com.openai.codex/web/Crashpad/pending，把路径换掉：

find Codex/Crashpad/pending -type f | wc -l
du -sh Codex/Crashpad/pending; sleep 60
du -sh Codex/Crashpad/pending

再确认处理器进程是否在跑：pgrep -lf browser_crashpad_handler

文件夹已经很大怎么办

先退出应用。#52194的报告者说，OpenAI支持让他们在应用关闭的状态下清理待上传报告——处理器还在跑的时候，你删它写。文件上百万时，rm pending/*会失败，因为shell把每个文件名都展开进一个参数列表，改用find -delete遍历：

cd ~/Library/"Application Support"
find Codex/Crashpad/pending -type f -delete

如果com.openai.codex/web/Crashpad/pending也很大，对它跑同一行。然后重启——#52194里管用的就是这个——再打开应用，重跑一遍增长检查。

如果文件夹还在长，#25921里的用户在修复版本落地前用定时任务清理，下面这行删掉超过24小时的转储：

find Codex/Crashpad/pending -type f -mtime +0 -delete

也有评论者用chmod把pending设成只读。另一些人提醒，这同时会挡住真正的崩溃报告传到OpenAI，如果这么做了，更新之后记得改回来。

本地队列都得有上限

一个只有上传成功才排空的文件夹，本质就是个队列。消费端永远不跑，队列就一路涨到磁盘满，而应用界面上看不出任何异常。Crashpad本来就有两个能兜住这件事的限制：数量和总大小。它们得被设上。

自己工具写出来的东西也一样：agent对话记录、重试队列、调试日志、崩溃报告。给每一项配一个大小上限和一个时间上限，磁盘快满时少写一点——这正是#51361请求Codex做的事。

一个消费端永不运行的无限队列，是系统设计里的经典失败模式，而且它出现的地方远不止崩溃报告器。