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