代码没写完，硬盘先冒烟？聊聊 OpenAI 官方 CLI 的重大日志事故及修复指南

最近用 Codex CLI 比较频繁的朋友，可以顺手检查一下本机的日志文件。

这次的问题不是“缓存太大”那么简单，而是 Codex CLI 会把运行日志写进本地 SQLite 数据库，路径一般在：

社区有人反馈，长时间运行后，这套日志机制会产生非常夸张的磁盘写入量。

更麻烦的是，文件大小看起来不一定一直上涨，因为它可能在不断“写入新日志、再删除旧日志”。也就是说，你看到数据库大小稳定，并不代表 SSD 没有被持续写。

先检查日志文件大小

可以先执行：

如果 logs_2.sqlite-wal 已经到几百 MB，甚至几个 GB，就建议优先处理。

再看它是不是还在持续写

更靠谱的验证方式，是看日志表的 ID 是否还在快速增长：

隔 60 秒再执行一次。

如果数字还在明显跳动，就说明它还在持续写日志。

优先升级 Codex CLI

目前 OpenAI 在 Codex CLI 0.142.0 已经加入了一部分修复，主要是减少 WebSocket 事件和重复遥测日志的持久化写入。

建议先升级：

截至 2026 年 6 月 24 日，我查询到的 @latest 对应版本是 0.142.0。

如果你的版本还是 0.141.x 或更早，建议尽快更新。

升级后别只看版本号

升级之后，最好不要只看版本号。

重新跑一遍上面的 MAX(id) 检查，确认日志写入真的降下来了。

因为有用户反馈，在 macOS 桌面 App 的 app-server 路径下，0.142.0 之后仍然可能存在部分日志 churn。

简单说就是：问题改善了，但不一定在所有场景里完全消失。

如果日志文件已经很大

可以先完全退出 Codex CLI 和 Codex 桌面 App，然后清理旧日志：

这会删除历史诊断日志，不会卸载 Codex，也不会删除你的配置。

但要注意，日志里可能包含本地路径、工具调用等诊断信息，不建议随便打包发给别人。

临时止血方案

如果你暂时不能升级，又发现写入还在持续，可以用 SQLite trigger 临时止血：

这个办法会阻止日志继续写入，适合临时自救。

缺点是后续排查问题时，会少掉一部分诊断记录。

Windows 用户也要注意

Windows 用户如果遇到“大文件写入时反复 Reconnecting、文件写不完”的问题，社区里也有人反馈这可能和 0.140+ 的另一个回归有关。

临时方案是降到 0.139.0：

建议处理顺序

Codex CLI 用户现在比较稳的处理顺序是：

1. 升级到 0.142.0 或更高版本。
2. 清理旧的 logs_2.sqlite*。
3. 用 MAX(id) 采样确认写入是否真的降下来。
4. 如果还在异常增长，再考虑临时 trigger 止血。

别等硬盘空间报警了才看。

这个问题最麻烦的地方，恰恰是它不一定表现为空间暴涨，而是悄悄消耗 SSD 写入寿命。