一个被忽略的角落：~/.codex 目录
我也是在 Reddit 上看到有人提到才意识到这件事。有人反馈说，他把 ~/.codex 目录下几个文件清理之后，Codex 的推理质量明显回升。底下一连串跟帖：有人 TUI 日志超过了 100GB，有人整个目录从 42GB 清理到 1.3GB。
这背后的逻辑其实不难理解。Codex 在本地会持续写入状态库、日志、会话记录这些东西，时间一长体积失控，读写就开始变慢。整体响应被拖累，给人的直观感受就是"它怎么变笨了"。
我去翻了一下自己的 .codex 目录，果然有几个文件大得不正常。从那之后，定期检查就成了我的习惯。
哪些文件最容易膨胀？
如果你也想排查一下，重点关注这几个：
~/.codex/state_5.sqlite— 本地状态库，存会话上下文~/.codex/logs_2.sqlite— 本地日志库，积少成多~/.codex/.codex-global-state.json— 全局状态和设置~/.codex/log/codex-tui.log— 终端界面日志，最容易疯长~/.codex/sessions/— 历史会话目录*.sqlite-wal和*.sqlite-shm— SQLite 的预写日志和共享内存文件，有时也会异常变大
这些文件的共同特点是：删掉之后 Codex 会自动重建，所以清理本身是安全的。但也正因为会重建，最好养成定期维护的习惯，别指望一次性搞定。
我的清理流程：保守但完全可逆
直接 rm 当然最痛快，但万一出问题怎么办？我的做法分五步，多花两分钟，换来的是随时可以反悔：
1. 先关掉 Codex，做个备份
完整备份整个 ~/.codex 目录，出任何问题都能直接还原。这一步看起来多余，但它是整个流程能保持"无心理负担"的关键。
2. 看看各个文件的大小
挨个看一遍，通常 codex-tui.log 是体积最大的那个。心里有数之后，再决定动哪几个。
3. 重命名，别直接删
把怀疑影响性能的文件加上 .old 后缀。这样万一清理完感觉不对，把后缀改回来就行，不用从备份恢复。
sessions/ 目录我一般只动那些明确不再需要的旧会话，最近在用的会保留。WAL 和 SHM 文件如果也很大，就同样改名处理。
4. 重启 Codex，跑一跑之前的任务
Codex 会自动生成新的文件。挑一两个之前明显感觉费劲的任务再试一遍，差别一般能立刻感觉出来。
5. 确认稳定后再清理 .old 文件
用几天觉得没问题了，再把那些 .old 文件删掉释放空间。万一觉得还不如之前，把备份目录覆盖回来，完全可逆。
日常维护的小习惯
我现在每隔一两周会把旧状态文件归档一下，保持主目录清爽。归档目录按日期命名，想回滚的时候也能精确找到当时的文件。
但还有一件事更重要——项目里真正重要的长期信息，别全压在 SQLite 里。
什么意思？架构决策、不能动的边界、踩过的坑，这些是你希望 Codex 每次都能读到的核心上下文。如果它们只存在于 SQLite 状态库里，那每次清理你都得纠结：清了会不会把重要的东西也清掉？
我的做法是写在项目根目录的 PROJECT.md 里。纯文本，不依赖任何本地状态，Codex 随时能读，清理多少次都不受影响。这样清理 .codex 目录就成了一件没有心理成本的事。
写在最后
这个方法不能保证 Codex 一定恢复如初——毕竟真正的服务端问题该有还是有。但它至少能帮你排除"本地文件膨胀"这个隐性干扰，让你判断问题到底出在哪一层。
如果你也感觉 Codex 时灵时不灵，下次发作之前，不妨先看一眼自己的 ~/.codex 目录。也许真正拖累它的，不是远在云端的模型，而是躺在你硬盘上那个悄悄长到几十 GB 的日志文件。
那么进一步想一下：除了 Codex，你日常用的其他 AI 工具，是不是也在本地默默写着类似的状态文件？