我知道开发工具吃硬盘。项目依赖、编译产物、本地模型，哪个都不小。
但用自己做的 MangoDisk 扫了一遍电脑，还是被一个项目吓到了：
较早的 Codex 崩溃报告：9.08 GB。
每天用 Codex 写代码，没想到它留下的崩溃报告，也能攒出这个体量。
代码还没写多大，崩溃报告先攒了 9 GB#
9 GB 的模型，我知道自己下载过；9 GB 的视频，我知道自己保存过。
9 GB 的崩溃报告？看到扫描结果之前，我根本没想过要去找它。
这才是“硬盘空间刺客”最烦的地方：你没主动存什么东西，可用空间却一直在减少。真要清理时，第一反应还是翻下载文件夹，删几个安装包。
截图里，整个“应用缓存”分类是 10.1 GB，光这一项就占了大约九成。旁边 741 MB 的 Google 更新器缓存，突然显得很克制。
这里说的是我这台电脑上扫描到的旧崩溃报告，不代表每个 Codex 用户都会遇到，也不能凭文件大小判断它到底崩溃了多少次。
但这个占用，确实值得应用自己管一管。
日志有用，也得有个限度#
出了问题，开发者要日志，这很合理。
可诊断文件保留多久、累计多大、什么时候轮转清理，也应该是软件需要处理的事情。不能功能交付了，留下来的文件全靠用户自己发现。
用户愿意把空间留给项目，不等于愿意把空间长期留给过去的故障。
尤其是开发工具。一个工具多留一点缓存，另一个多留一点构建产物，用到最后，电脑里装的仿佛不是软件，而是它们的历史遗迹。
这也是我做 MangoDisk 的理由#
这次扫描让我觉得，清理工具最有用的一刻，就是把这种意料之外的占用摆到眼前：哪个应用、什么文件、多大。
截图里的 MangoDisk 已经把旧崩溃报告单独列了出来，旁边可以展开查看，AI 解读也给出了用途和清理前的提醒。至少不用先搜一圈“Codex 的缓存藏在哪”，再对着一个陌生目录犹豫。
当然，扫描结果不等于已经释放的空间。截图顶部的 150 GB 是整次扫描的估算，也不是 Codex 一家的占用。这张图记录的是清理前的发现。
真要处理，仍然应该先确认具体文件；如果还需要排查崩溃，就保留相关报告，并按提示退出应用后再操作。AI 解读可以辅助判断，不能当成随便删整个目录的依据。
MangoDisk 是我开源的磁盘清理工具，源码在 GitHub。这张截图就是它在我自己电脑上扫出来的。
下次空间告急，我会先看看这些应用留下了什么。下载文件夹已经替它们背了太多次锅。