在你的Mac上还剩多少可用空间？一位用户在得知答案时，发现仅剩下可怜的1.4 GB。10月17日，这名Mac用户在Codex的GitHub问题追踪中附上了一张图，显示了两个崩溃报告文件夹中，存有大约400万个文件，合计占用的硬盘空间竟达到323 GB。他表示，这个数字占据了926 GB硬盘总容量的35%，而在发现这一问题之前，他的可用空间已经降到仅剩1.4 GB。令人关注的是，这个问题在6月2日便已被提出，标题直截了当地表明了Bug的性质：Codex桌面端持续生成的Crashpad待上传转储文件，已经无上限地膨胀，日均增加至少5GB。
随着时间的推移，问题的严重性逐渐暴露。这些数据全部来自用户在issue跟踪器及OpenAI论坛上的反馈，并没有任何OpenAI自己进行的测试支持。6月2日的第一份报告显示，一天内便产生了4.9 GB的崩溃转储文件和54504个文件。而在issue #36982中，应用版本为26.727.51351，出现的增长速率竟高达每日约17GB。到9月23日，issue #47466的内容显示，macOS 15.2系统下，文件夹的大小已达511 GB，应用运行时每秒大约生成160 KB的minidump文件。更为惊人的是，10月6日的统计显示崩溃转储达到了130.53 GiB，而剩余可用空间仅为821 MiB，用户甚至开始收到“设备空间不足”的错误信息。而在10月8日，另一个追踪更新则显示，崩溃文件总量逼近168 GB，文件数接近197万个。10月16日，另一条论坛帖子更是估算其总量已高达230 GB。10月17日的评论中，一位用户还特别标注了自己使用的构建版本：ChatGPT.app 26.1007.71326。
这个问题的复杂之处在于，尽管应用本身在持续运行，但用户却无法察觉到被疯狂增长的文件夹。早期的报告者提到，该应用始终可用，让这个崩溃报告文件夹在数周内悄然膨胀，直到有人开始关注它。 谈球吧app
那么，为什么这个崩溃报告文件夹一直无法清除呢？Crashpad是一种用于捕获、存储和传输崩溃报告的库，最初源于Chromium项目。它的数据库中暗藏的是“待上传的崩溃转储”文件，即存放在待处理文件夹中的那些数据。当前，问题的主要解释来自用户反馈，而非OpenAI的官方回应。在#25921中，一名用户指出每个转储都是来自于崩溃处理器本身——browser_crashpad_handler。多名用户提到过相同的启动失败：调用mach_port_request_notification时返回"(os/kern) invalid capability (20)"，并伴随着检查失败的信息，结果导致进程崩溃。该进程会被重启，但又会再次失败，并写入新的转储。#36982标题简洁地总结了此现象：处理器在“启动2毫秒后SIGTRAP，launchd便将其重新拉起”。另外，在#25921中，其他用户还证实在macOS Tahoe 26.3.1的其它Chromium和Electron应用中也出现了相似的故障。
问题的另一半则在于，没人会对这个文件夹进行“清理”。根据Crashpad的设计文档，数据库应该存储可配置数量的崩溃转储，并有一个最大聚合大小的上限。然而，在#25921的评论中，有人提到该应用并没有正确使用Crashpad的清理工具。与此同时，#51361请求OpenAI默认启用存储上限和清理功能，但目前这一问题依然悬而未决，且没有人被指派负责处理。
是否修复了这一问题？也许是一小部分。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的讨论依然在继续。 谈球吧app
另一个细节在于，#52194中提到的报告者发现，尽管一些旧版框架的处理器进程仍在运行，但那些版本已经不再存在于磁盘上。即便是强行关闭进程也无济于事，重启Mac是解决问题的唯一方法。
如果你也想检查自己的Mac，首先进入issue中列出的两个位置，分别是旧旧和新路径，并使用命令行工具de进行大小统计： 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
