Codex的空间危机：323GB的崩溃日志问题

10月17日，一位Mac用户在Codex的GitHub问题页面上贴出了他们的存储状况，揭示了他的硬盘可用空间仅剩1.4GB。他发文提到，硬盘中有两个崩溃报告文件夹，里面一共存储了大约400万个文件，累计达到了323GB，这相当于他的926GB硬盘总容量的35%。他表示在发现这个问题之前，硬盘的可用空间已经急剧减少。自6月2日开始，该问题一直未能解决，标题直述问题所在：Codex桌面版本不断生成Crashpad待上传转储文件，且无上限增长，每天至少增加5GB。

据论坛和问题追踪器的数据，这些数字均来自于用户反馈，而非OpenAI官方测试。最早的报告记录显示，一天内就增加了4.9GB和54504个文件，后续的问题反馈也持续增大，例如不同的问题编号报告显示，应用版本为26.727.51351的用户，数据增长速率达到了每天17GB；而在9月23日的报告中，随着应用运行，文件夹的容量达到了511GB，几乎是实时生成160KB的minidump文件。其他报告则显示，时间经过几天后，空间已减少至821MB，从而引发了“设备上没有剩余空间”的错误。

更让人困惑的是，该应用在发生崩溃的情况下仍能正常运作，因此这个文件夹在几周内悄然增大，不被注意。Crashpad是Chromium项目专门用于处理崩溃报告的工具，其工作原理是捕获、存储并传输崩溃报告。“待上传的崩溃转储”便是存储在其数据库中的文件。用户的反馈表明，Crashpad中的转储数据来源于崩溃处理器本身，一些报告提及了启动失败的错误。

造成这个问题的另一个原因是，Crashpad没有对崩溃转储进行清理，设计文档指出其可以配置最大存储数量，但网友回馈说明当前应用未能使用Clean Up功能。尽管有来自用户的请求要启用默认的存储上限和清理选项，这些反馈至今未得到解决。

关于这个问题的修复，有部分用户在10月6日讨论时提到，似乎是旧版Mac内核导致的问题，并且有报道称修复已完成并会尽快发布。然而，当用户询问哪个版本包含这个修复时却未得到回应。早期的一位贡献者在6月14日时曾说明该问题在更新版本中已得到解决，但随后用户在多个macOS版本上依然看到空间的增加。

截至10月17日，用户报告显示仍在macOS 15.7.4上运行，尚不清楚是否应用了早前的修复。同时，另有用户报告发现旧版本的处理器进程依旧在后台运行，无法通过简单关闭进程解决，必须重启设备才能打破这个恶性循环。

最后，如果你想检查自己的Mac存储情况，可以根据问题页面中提供的路径进行操作，通过命令查看二个特定目录下的空间使用情况。如果发现其中的转储文件堆积过多，就意味着应用存在问题影响了你的存储效率。