一个应用一直正常开着，硬盘也能只剩 1.4 GB。全程一句提醒都没有。
怎么发生的。
先把数字摆出来。10 月有个用户在 ChatGPT.app 上量了两个 Crashpad 目录，合计约 323 GB，约 404 万个文件。他那块盘 926 GB，被吃掉三分之一还多。删完之后几分钟，可用空间从 1.4 GB 回到 50 GB 以上。
最要命的是，应用一直能用。
这期本来能收五六条。最后只留了这一条。剩下的要么我讲不清它对普通人意味着什么，要么讲了也只是转述。
一句话搞懂 Crashpad 是什么
简单说，它是应用崩了之后，先在本地把现场记下来、等着上传的那块缓冲区。
pending 就是还没送出去的队列。每个崩溃现场是一对文件，一个 .dmp 装内存现场，一个 _sidecar.json 装说明。正常情况下这份队列应该很短，传完就清。
问题出在这里。Crashpad 自己带了清理器，这个应用没有把它打开。8 月有人指出这一点的时候，这个 issue 已经开了两个多月。
然后是循环
9 月有位用户把根因拆清楚了。每一个 .dmp 记的都不是应用主体崩了。是 browser_crashpad_handler 自己崩了。错误打在 exception_handler_server.cc:76。信息是 mach_port_request_notification 返回无效能力 20。系统日志里反复出现 EXC_BREAKPOINT 和 SIGTRAP。这个处理器自己在崩溃、被拉起来、再崩溃。
测出来的速度是每秒一份。一份 181,552 字节，加 24 字节 sidecar。折算下来每小时 0.6 GB，每天 15 GB。
一天 15 GB 是什么概念。你出差一周，回来少 100 GB，而你只会觉得是系统更新占了地方。
这条我原本想写成「怎么清理磁盘」，写到一半觉得不对
清理是下游。真正值得抄的是它为什么能长这么久。没有一个地方设了上限。
中间有人试过不少办法。6 月清理完 4.9 GB 之后，新的成对文件立刻又出现。有人重装、禁用 bundled 的 browser、在 config.toml 里清空后端列表，重启后照旧。有人把 pending 目录设成只读加不可变，目录确实停在 0 个文件。这是把闸门焊死，副作用是崩溃报告再也写不进去，修复之后得把权限还回来。6 月还出过一个 cron，每 15 分钟删一次第一层文件。
到 10 月，有人给出的版本更像样。一个每五分钟跑一次的 LaunchAgent，把超过 24 小时的上报过期掉，pending 和 completed 两个队列各限 64 组、256 MiB 以内。
这就是可以抄的那份作业。不是「记得定期清」，是「给会自己长文件的目录写死一个上限」。清理靠人记，上限靠机器。
几个数字，感受一下增长没被拦住
6 月 2 日刚开 issue 那会儿，一天 4.9 GB，54,504 个文件。同一个月里，有人报到 59 GB。有人说文件数撞到 65,535 之后后台还在写。还有人报 61 GB、738,864 个文件。8 月中，100 GB、约一百万个文件。9 月初，174.6 GB，两百万个文件，目录链接数饱和在 65,535。9 月下旬那台机器累积到 21 GB 的时候，已经试过把 228 GB 的盘用到 0 字节可用。10 月 5 日有人清掉 1,212,428 个文件，分配大小 114 GB。
单个 .dmp 大部分不到 800 KB，有的只有 161 KB 上下。总量全是小文件堆出来的。这也是它容易被忽略的原因。文件管理器打开那个目录会卡，卡到你不想看第二眼。
这不是一家的事
同一类 Crashpad 报错，在 Claude Desktop 和 VS Code 的仓库里也有人提。上游的触发条件不在某一家手里。
这条我只看懂一半。上面那层「处理器自己的启动检查失败被当成可报告崩溃」的逻辑，怎么改才不误伤真崩溃，我说不清。先放在这里，搞明白了再补。
关于「已经修了」
10 月中旬有人在 issue 下汇总，说针对旧版 Mac 内核的修复已经合并。报告里受影响的系统多数是 15.x 或者 26.0 到 26.3，26.5 以上的用户说没遇到。
我对这句话持保留。不是怀疑那个人，是这类结论在这个 issue 里出现过不止一次。6 月中就有贡献者说较新的 macOS 至少 26.5 已经解决，然后 8 月、9 月、10 月陆续还有人报。7 月还有人做过比对，说新 build 和旧 build 的 Chromium 版本、Mach-O UUID、未签名代码段 SHA-256 完全一样，单靠回滚躲不掉。
判断修没修，我看两点。新版本里那个清理器有没有打开，pending 有没有尺寸上限。这两件事，没有一样是靠升级系统版本能保证的。
给普通人的动作
去这两个路径看一眼，把占用算一下：
~/Library/Application Support/Codex/Crashpad/pending ~/Library/Application Support/com.openai.codex/web/Crashpad/pending
第一个是新的，第二个是旧的。旧的更可能是个没人管的积压。有人的新路径只有 20 KB，旧路径 137 GB。
然后删掉。删之前最好把应用退掉，不然新的会立刻长回来。
再然后，设个上限。上面那个 LaunchAgent 的思路就够了，过期加容量封顶，两件事分开做。macOS 上磁盘吃到 0 字节可用不是「慢一点」，是会直接把系统拖进奇怪状态。
补一句。你的机器上现在没报这个问题，不代表它三个月前没长过一堆没人清的东西。这类目录不会通知你。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。