FangYuan·4 小时前
Codex 的 Other 占了近 80 GB，我是怎么查清楚的
打开 Codex 的 Storage，我看到 Other 占了 78.5 GB，整个应用占用 81.5 GB。后来继续排查，一个插件市场升级暂存目录就有 76.44 GiB。
我先清理了 90 天前的旧聊天，但 Other 里这个大头是什么，还是没弄清楚。工作树只有 6 kB，我没动；已归档聊天在前一轮处理过，也没重复清理。
于是我又开了一个聊天，让 Codex 帮我查。排查报告指出，占空间的是本机 .codex 下面的 .tmp/marketplaces/.staging。我的要求是先确认哪些还在使用，再处理确认闲置、可以删除的目录。
当时的报告记录，删除了 743 个确认闲置的目录，保留了 56 个近期或仍被使用的目录；本轮移除了约 71.61 GiB 的文件占用，暂存目录从 76.44 GiB 降到 4.84 GiB。
报告里的检查不只是“目录够不够旧”，还包括有没有进程引用、外部符号链接引用或锁文件，删除前又核对内容是否变化。“超过 24 小时”只是当时检查的一部分，不能单独当作可删标准。
副本为什么会堆起来？Codex 根据当时的本机日志和目录记录判断，插件市场反复更新，部分升级暂存没有及时回收；CloudBase 的克隆超时又加重了累积。这是我这台电脑的排查结果，我没有独立确认它是不是某个版本的普遍 bug。
后来我关闭了相关插件市场的自动更新，把更新和闲置目录检查集中到每周处理。按周更新会有时间差，这是我自己接受的取舍。
之后又高强度用了一天 Codex，再看 Storage：总占用 6.1 GB，Other 3.9 GB。我后来用了一两天插件，没有发现使用受到影响，后面还要继续观察。
前后数字来自不同时间的截图与报告，GB 和 GiB 也保留原始单位，不能把两张截图直接相减，当成一次操作准确释放的空间。你的 Other 也未必是同一种文件。
如果也碰到类似情况，可以先让 AI 只读检查大目录、用途和使用状态，拿到清单后再决定处理哪些。别看到 Other 很大，就直接清空目录。
