Codex 的日志正在悄悄吃掉你的 SSD

你的电脑最近变慢了吗？#

不是因为硬件过时，也不是因为你装了太多流氓软件。如果你在用 OpenAI 的 Codex，真正的元凶可能藏在你不会去看的地方： ~/.codex/logs_2.sqlite。

打开 GitHub 上的 issue #28224，你会发现一条令人不安的线索。有用户发现，自己的机器在连续运行 21 天后，Codex 向主 SSD 写入了大约 37 TB 的数据。什么概念？按这个速度，一年的写入量能达到 640 TB。而市面上多数消费级 1TB SSD 的标称总写入寿命（TBW）也就 600 TB 左右。换句话说，这个 bug 可以在一年之内把你的 SSD 写到报废。

一个计数器，暴露了 10,000 倍的差距#

这个 bug 的根源藏在 Codex 的日志系统里。它会把每一个 WebSocket 事件都原原本本地记到 SQLite 数据库里，一条不落。结果是什么？数据库里实际只保留了大约 50 万行有效记录，但 SQLite 的 AUTOINCREMENT 计数器已经飙到了 55 亿。

50 万对 55 亿——差距超过 10,000 倍。你可以把 SQLite 想象成一个笔记本，每写一页就撕掉旧的，但你持续在封面编号上累加。封面数字不会骗人：这 21 天里，每一秒都有几十甚至上百个事件被写进日志文件。

SQLite 的 Write-Ahead Log（WAL）机制会进一步放大写入量。每次写入都会产生额外的 WAL 文件操作，让 SSD 承受了比实际数据量更大的写入压力。硬件的磨损就在这种无声的循环中加速。

六月二十二日，两个关键的修复#

社区没有坐视不管。6 月 22 日，两个 PR 被合并进主分支：Stop logging every Responses WebSocket event (#29432) 和 Filter noisy targets from persistent logs (#29457)。据提交者估算，这两项改动可以消除大约 85% 的日志洪水。

换句话说，理想情况下，之前的年写入量可以从 640 TB 降到 100 TB 不到——虽然仍然不算温和，但至少不会在 12 个月内把一块新 SSD 的写入寿命彻底吃干抹净。

检查一下你自己的机器#

这个 bug 影响的不仅是运行 Codex 的开发者。如果你在团队中共享依赖 Codex 的后端或构建节点，所有运行了 Codex agent 进程的机器都可能已经被波及。

你可以做两件事。第一，更新到最新的 Codex 版本，确保那两个修复已经包含在内。第二，检查自己的 SSD 健康状态——在 Linux 上可以用 smartctl 查看 Total_LBAs_Written，macOS 用户可以在系统信息中找到 “Total Data Written” 指标。如果过去几个月的数据增长曲线异常陡峭，你可能需要留意一下写入量。

SSD 的寿命是慢慢消耗的，但 bug 让它快进了。好在问题已经被找到，修复也已经在路上。剩下的，就是确认你的机器不在那 85% 的拯救范围之外。