如果你的 Mac 空间总是莫名其妙变少，而你又在用 Codex 桌面应用，有一个文件夹值得看一眼。OpenAI 的 Codex 仓库里有一个从 6 月开到现在的 GitHub issue，汇集了不少 Mac 用户的反馈：Codex 一直往 Crashpad 文件夹里写崩溃转储，最后占掉几十 GB，有人甚至到了几百 GB。这个 issue 在北京时间 10 月 18 日 01:45 被发到 Hacker News，到下午有 118 分，当天 issue 里还在不断有人补充新的情况。
用户遇到了什么
issue 是 GitHub 用户 Jolg42 在北京时间 6 月 3 日 03:09 开的。他说 ~/Library/Application Support/com.openai.codex/web/Crashpad/pending 这个文件夹一天之内涨到 4.9 GB、54,504 个文件，全是成对的 .dmp 和 _sidecar.json，他排查的时候数量还在往上涨。这期间应用一直能正常用，这也是问题不容易被发现的一个重要原因。Jolg42 后来补充说，删掉这些文件后文件夹降到几 MB，但新的文件对马上又开始出现。
之后有人报出了大得多的数字。一位 macOS 15.6 用户说文件夹涨到了约 137 GiB，另一位测到 174.6 GB。北京时间 10 月 18 日 01:37，一位 macOS 15.7.4 用户说 Codex 的两个 Crashpad 文件夹加起来约 323 GB，占了 926 GB 磁盘的约 35%，等他发现时可用空间只剩 1.4 GB。他写道：「应用里什么提示都没有（Nothing in the app warned me）。」几位用较新版本的评论者发现，在 Codex 并入 ChatGPT 桌面应用之后，同样的堆积出现在另一个位置：~/Library/Application Support/Codex/Crashpad/pending。这个 issue 标着 bug、app 和 performance，目前仍未关闭。
背后可能是什么原因
OpenAI 没有解释原因。打开过这些转储的用户说，它们记录的是 Crashpad 自己的处理进程 browser_crashpad_handler 的崩溃：这个进程启动时一项检查失败，被重新拉起来，又失败，每次都写下一份新的转储。有评论者测到正好每秒一份。也有人指出，pending 文件夹从来没有东西去清理，所以就算崩溃没那么频繁，几个月下来也会越攒越多。
哪些 macOS 版本受影响
这是最说不清的部分。北京时间 6 月 15 日 01:50，被 GitHub 标为 Codex 仓库贡献者（contributor）的用户 dnakov 写道：「I think this is fixed with later macos versions. at least in 26.5 it is」，意思是他认为新版 macOS 已经没这个问题，至少 26.5 上是这样。8 月有另一位用户追问，这是不是指 macOS 那边有已知的修复、还需不需要更新 Codex，issue 里一直没人回答。北京时间 10 月 18 日 13:18，用户 nathanvy 说自己在 macOS 26.6.2 上用 Codex 26.1013.40934，似乎没有受影响，并建议从 macOS Sequoia 升级上来也许能解决。issue 里写明了 macOS 版本的受影响报告，用的都是 macOS 15 或者 26.5 之前的 macOS 26，不过这只是少数人的自述，不是测试结果。OpenAI 没有在 issue 里回应，Codex 更新日志里也没有提到这个问题或修复。
怎么查看和清理
想看这个文件夹有多大，可以在访达的「前往」菜单里选「前往文件夹」，粘贴路径，再对 pending 文件夹点「显示简介」。用终端的话，du -sh "$HOME/Library/Application Support/Codex/Crashpad/pending" 也能看到，把路径换成旧的 com.openai.codex/web 那个就能查另一处。如果里面有几十万个文件，两种方法都可能要等一会儿。
如果确实很大，先退出 Codex；如果你是在 ChatGPT 应用里用 Codex，就退出 ChatGPT 应用。然后只删 pending 文件夹里面的文件，别的都不要动。这些是 Crashpad 排着队、还没发出去的崩溃报告，评论里删过的人都说空间回来了，应用之后也照常能用。其他的都别碰，包括 Crashpad 文件夹里的其他部分，以及放着应用自己数据的 Application Support/Codex 文件夹。另外，评论者们都没有公开上传自己的转储文件，因为里面可能有进程内存、本地路径之类的私人信息。
清空文件夹只是把空间腾出来，并不能让产生转储的问题停下来。重新打开 Codex 过一阵子，可以再看看文件夹有没有又涨起来。有评论者更进一步，把 pending 文件夹设成只读来止住增长，但也有人提醒，这只是紧急刹车，正常的崩溃报告也会写不进去。OpenAI 如果回应或者推出修复，我们会更新这篇文章。
