想象一个场景：你买了一台新 MacBook，装好 Codex CLI 就开始用它写代码。每天开着终端，Codex 在后台帮你补全、重构、调试。三个月后，你发现电脑越来越慢，打开 Activity Monitor 一看，磁盘写入量已经超过了 150TB。翻遍进程列表，凶手正是那个你最信任的 AI 编程助手。

这不是虚构。2026 年 6 月 14 日，GitHub 用户 1996fanrui 在 Codex 仓库提交了一个 Issue，标题简洁但触目惊心：「Codex is writing 640 TB/year to my SSD」。

一个被忽视的「诊断日志」#

问题的核心藏在 ~/.codex/logs_2.sqlite 这个不起眼的文件里。

Codex CLI 内部有一个日志子系统，它把运行期间的所有事件，包括每一次工具调用、每一段 WebSocket 消息体的完整内容、甚至每次对 /etc/passwd 和 ld.so.cache 的平凡文件访问，全部写入一个本地的 SQLite 数据库。

关键不在于「记录了日志」，而在于以什么级别记录。

Codex 的 SQLite 日志 sink 默认运行在 TRACE 级别。在传统日志体系里，TRACE 是最低层级，用于调试极其底层的代码执行细节。正常发布的软件产品要么默认关闭 TRACE，要么只在用户主动开启时才启用。但 Codex 的日志子系统不仅默认开 TRACE，而且完全忽略 RUST_LOG 环境变量，用户没有任何办法调低日志级别。

更糟糕的是，根据社区分析，约 71% 的写入数据属于 TRACE 级别的噪音日志，对普通用户来说毫无意义。你花钱买的 SSD 寿命，正在被一堆你看不见也用不上的日志数据匀速消耗。

640 TB 是怎么算出来的#

1996fanrui 的机器上有一块 1TB SSD。他在 21 天里积累了约 37TB 的写入量，折合每天约 1.76TB。按这个速率往下推，一年就是 640TB。

对机械硬盘来说，640TB 可能不算什么。但消费级 SSD 有「写入耐久度」这个概念，通常用 TBW 来衡量。

一块典型的 1TB 消费级 NVMe SSD，TBW 一般在 600 左右。也就是说，厂商保证它在写入 600TB 数据后仍能正常工作。640TB 已经超出了这个额定值。换句话说，如果你开着一台 Codex CLI 并让它持续运行，你的 SSD 可能在不到一年内就达到甚至超过厂商的耐久度上限。虽然 SSD 通常不会在到达 TBW 后立刻罢工，但数据安全已经不在保障范围内了。

写放大：看不见的第二把刀#

如果只是数据库文件缓慢增长，问题还不至于如此严重。真正致命的是写放大。

SQLite 数据库在频繁的插入和删除操作下，内部会产生大量的页分裂、B-tree 重组、WAL 文件刷新。表面上看 logs_2.sqlite 可能只有几百 MB，但底层的物理写入量可能是文件大小的几十倍甚至上百倍。

代码分析显示，日志子系统不仅不断往 SQLite 里塞数据，还在高速循环地进行「插入—删除—插入」操作。每一轮操作都触发一次物理写入。成千上万次小操作叠加起来，真正写进 NAND 闪存的数据量远超数据库文件本身体积。

这就是为什么一个看起来人畜无害的 SQLite 文件，能在几周内吞噬掉几十 TB 的写入预算。

为什么现在才被发现#

这个问题其实不是新鲜事。早在 2026 年 4 月，就已经有相关报告浮出水面。有人提到 logs_2.sqlite 在持续增长，有人怀疑是 WebSocket 日志太多。但这些早期的声音被淹没在大量的功能 Feature Request 中，没有引起足够重视。

直到 1996fanrui 贴出了精确的硬盘 SMART 数据，Data Units Written: 37,324,112,445，配上「640 TB/year」的推算，事情才开始发酵。这个 Issue 在不到一周内收获了 464 个 👍 和 253 条评论，成为 Codex 仓库近期最受关注的议题之一。

OpenAI 的更新日志显示，他们近期做过一些 SQLite 可靠性修复，但没有触及写入速率的问题。截至 6 月 22 日，这个 Issue 仍然处于开放状态。

这里反映出一个更深层的问题：当 AI 编程工具越来越复杂，内部依赖越来越多，工程师团队是否具备足够的动力和机制去关注「非功能性问题」？日志量过大不会导致 CI 变红，不会触发报警，不会影响测试覆盖率。它只是在静默地消耗硬件资源，这种问题最容易在 Code Review 和 QA 流程中溜过去。

临时修复方案#

在官方修复发布之前，有一个简单的临时方案：

把 ~/.codex/logs_2.sqlite 软链接到内存文件系统 /tmp/，让日志写入发生在 RAM 中而不是 SSD 上。

# 备份原文件（如果需要）
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak

# 创建软链接指向 /tmp
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite

这个方案的好处是零副作用。日志文件不包含任何对话数据或用户内容，丢失了也没关系。重启后 /tmp/ 被清空，SQLite 会自动重建一个新的空数据库。

Linux 和 macOS 用户都可以使用这个方法。Windows 用户可以用类似思路，将文件链接到 RAM Disk。

我的看法：AI 工具的「隐蔽税」#

这个 Bug 让我想到一个概念，我称之为 AI 工具的「隐蔽税」。

Codex 这类工具的价值主张非常清晰：让你写代码更快、更省力，把重复劳动外包给 AI。用户看到的是效率提升，感受到的是「少打字多产出」的快乐。但很少有人会去关注工具本身在消耗什么。

这次暴露出来的，是磁盘寿命。下次可能是内存（Codex 的内存占用本身就不低），再下次可能是网络带宽（WebSocket 日志意味着连接始终活跃）。每一次技术上的不克制，都在默默地向用户征收一笔看不见的税。

这不仅是 OpenAI 的问题，而是整个 AI 工具行业的通病。Claude Code、Cursor、Copilot，它们都在后台持续运行，都在写缓存、写索引、写日志。如果每个工具都像 Codex 一样「豪放」，一台开发机的硬件资源很快就会被瓜分殆尽。

对于开发者来说，在享受 AI 便利的同时，定期看一眼 iotop、btm 或 Activity Monitor 的磁盘写入量，可能是一个值得养成的新习惯。你的 SSD 不会告诉你它正在被缓慢地杀死，直到为时已晚。

参考来源：