最近刷到一个 Codex 的坑，真的有点离谱。 有用户反馈： 明明没有频繁操作 Codex，但后台的日志文件一直在疯狂写入： "~/.codex/logs_2.sqlite" 最夸张的实测是： 21 天写了 37TB。 这是什么概念？ 很多普通 SSD 的寿命也就几百 TBW。 如果长期这样写，硬盘寿命可能真的会被悄悄消耗掉。 问题主要出在 Codex 的诊断日志写入太激进，尤其是一些 TRACE 级别日志、WebSocket 事件之类的内容。 我建议正在用 Codex CLI 的人，先做这 3 件事： 1. 先升级 Codex 官方已经在新版里修复了日志写入问题。 终端执行： codex upgrade 升级后重启 Codex。 2. 检查日志文件大小 Mac / Linux： du -sh ~/.codex/logs_2.sqlite* Windows 可以打开： %USERPROFILE%\.codex 看看 "logs_2.sqlite" 有没有异常变大。 3. 文件很大就清理旧日志 只清理 "logs_2.sqlite" 相关文件就行，别乱动其他配置文件。 如果你暂时不能升级，也可以用 SQLite trigger 阻止继续写入日志。 但对大多数人来说，优先升级是最稳的办法。 这类问题最麻烦的点在于： 你平时几乎感觉不到，等发现时可能已经写了几十 TB。 所以如果你最近在高频用 Codex，真的建议现在就检查一下。 AI 编程工具很好用，但这种隐藏成本也不能忽略。 别让代码还没写完，SSD 先被写麻了。 #Codex #OpenAICodex #AI编程 #AI编程工具 #程序员日常 #硬盘寿命 #SSD #AI工具 #效率工具 #技术避坑