Codex磁盘占用清理指南：用CX Clear安全释放本地空间

代码写久了，磁盘空间永远不够用，这是所有开发者的共识。但最近让我真正难受的不是 node_modules，而是 Codex。跑了一两周的 Codex 任务，我发现自己的主目录和缓存分区莫名少了十几个 G，一查才发现日志、会话记录、沙盒残留堆了一堆。手动清理过两次，一次删多了导致需要重新认证，一次漏删了，过两天磁盘又变红。后来试了 CX Clear 这个专门针对 Codex 本地占用做扫描与清理的小工具，算是把这个问题彻底解决了。这篇文章就把 Codex 的占用构成、CX Clear 的设计逻辑、完整实操流程和踩过的坑一次说清楚，适合重度使用 Codex、磁盘吃紧、以及不想在文件系统里翻来找去的开发者参考。

1. Codex 到底在本地留了些什么？先摸清占用的源头

1.1 三类最常见的本地产物：日志、会话记录、沙盒残留

很多人的第一反应是“Codex 不是云端的吗？为什么本地会占空间”。这句话对了一半。Codex 的核心推理确实在远端模型服务上完成，但它落地到你本地的部分远比你想象的多，而且这三类产物互相独立，增长速度也不同。

第一类是操作日志。Codex CLI 在执行任务时会输出大量分级的日志，包含任务细节、请求时间、模型响应摘要、本地环境检测结果等。这类文件通常以 .log 或者纯文本形式存在，初期一天可能只有几 MB，但长期跑下来，尤其是频繁调试、反复重跑任务的时候，几百 MB 到几个 G 都很正常。我给它的定义是“纯可再生垃圾”，删掉对使用没有任何副作用。

第二类是会话与任务记录。Codex 会保留每次对话或任务的数据，包括你输入的 prompt、它生成的回复、任务快照、上下文摘要等。对重度用户来说，这部分才是空间大头。一条长会话可能几 MB 到几十 MB，如果你习惯同时开很多条会话来对比不同方案，那这个目录涨起来的速度非常惊人。但这类又不能一股脑全删，毕竟你还需要回看之前的思路，甚至把某个旧任务恢复到可继续编辑的状态，删了就真没了。

第三类是沙盒与临时文件。Codex 在执行代码时会做隔离处理，常见做法是在本地创建一个受限的执行环境，里面会缓存依赖包、生成临时脚本、写入检查点快照。任务结束后，很多环境清理并不彻底，于是“临时”就变成了“常驻”。这类文件的特点是单个体积大、命名随机、看起来像系统文件，你敢不敢删完全取决于你有没有搞清楚它属于哪个任务。

这三类加在一起，就是一个“临时车库”的经典场景：车开进去的时候带了一堆杂物，走的时候钥匙一拔就不管了。你每天往里开几趟，车库里的东西只会越来越多。

1.2 手动清理为什么会越清越心累

手动清理听起来不复杂，无非就是找到目录、delete、清空回收站。但实际操作时你会发现四个很现实的问题。

第一个问题是分不清“缓存”和“数据”。我用文件管理器打开过 Codex 的本地目录，里面密密麻麻的全是看起来差不多的 JSON、日志和临时文件。你不打开文件内容，根本不知道某一条 20MB 的记录是一次失败的沙盒执行残留，还是你上周写一个重要需求时的完整分析过程。我最早手动清理时就把一段还没合并完的需求记录删了，后来找半天没找回来，只能当场重跑一遍任务，白白浪费了大半天。

第二个问题是路径分散。Codex 的数据并不只在一个目录里。用户配置目录有一份、系统缓存目录有一份、临时目录还有一份，Windows 下可能还有额外的工作目录和 daemon 相关路径。手动清理很容易盯着一个目录猛删，另外几个目录完全没注意到。最后的结果就是“看起来清了一大堆，磁盘空间几乎没动”。

第三个