如果你最近在用 OpenAI 的命令行编程工具 Codex，有件事值得花两分钟看一下：它有一个日志 bug，会在后台默默往你硬盘里狂写数据，写到足以让 SSD 提前报废的程度。
到底有多狠
Codex 运行时，会把日志写进本地的一个 SQLite 数据库，文件在 ~/.codex/logs_2.sqlite。麻烦在于，它默认的日志级别被设成了 TRACE，也就是“事无巨细全记下来”的最高一档：每一帧 WebSocket 通信、每一次普通的文件读取，全都往里灌。
有人把 Codex 挂着连续跑了 21 天，回头一查，这个日志文件已经往硬盘里写进了大约 37TB。年化下来，差不多是 640TB/年。
这个数字意味着什么？一块普通的 1TB 消费级 SSD，厂商标称的写入寿命（TBW）大约就是 600TB。换句话说，光是让 Codex 这么挂着，不到一年就能把整块盘的质保寿命写干净，相当于一年内把它从头到尾覆写 640 遍。
实际损耗还要更重。这个数据库每分钟要执行几万次插入和删除，真正落到闪存颗粒上的物理写入量（也就是所谓的“写入放大”），比文件本身的体积夸张得多。
为什么会写这么多
两个叠加的设计问题。
一是日志级别默认就是最吵的 TRACE。按官方修复时给出的统计，光“记录每一个 WebSocket 事件”这一项，采样里就占了 527MiB；TRACE 噪声占了保留日志的七成，再加上一份重复的遥测日志，算下来差不多 96% 的日志都是毫无诊断价值、可以直接删掉的废数据。
二是它还无视了 RUST_LOG 这个环境变量。这本来是同类程序里调日志级别的标准开关，正常设一下就能让它小声点，但在 Codex 这儿设了也不生效，普通用户根本没有顺手的办法把它关小。
更尴尬的是，这并不是突然冒出来的问题——从今年 4 月起，就陆续有人以各种形式反馈过，只是一直没被重视。
现在该怎么办
好消息是，官方已经修了。 6 月 22 日，这个 issue 被正式修复：两处改动合入主分支，一处停掉了“记录每个 WebSocket 事件”，一处把最吵的几类日志直接过滤掉，据测算能砍掉八成以上的日志量。所以最省事的办法很简单：把 Codex 升级到最新版本。
如果你一时升不了级，可以先把那个日志文件软链到 /tmp，别让它落在主盘上：
mv ~/.codex/logs_2.sqlite /tmp/
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite
这个文件里不存对话内容，重启丢了也没关系。但有一点要提醒：网上常说“软链到 /tmp 就等于写进内存”，这只在 /tmp 被挂成内存盘（tmpfs）的 Linux 上才成立；macOS 的 /tmp 默认仍然落在磁盘上，这么做只是把写入挪了个位置，并不能真正避免落盘。想彻底解决，还是升级最稳妥。
写在最后
一个帮你飞快写代码的工具，反过来可能先磨坏你的硬件，这事本身就挺值得琢磨。它也提醒我们：这类长时间挂在后台跑的 AI 工具，默认配置里埋的坑，往往不在你盯着的那块屏幕上，而是在磁盘、网络、账单这些平时不会去看的地方。下次让一个 agent 长跑之前，不妨顺手看一眼，它到底在你机器上写了多少东西。
参考链接：
- GitHub issue：openai/codex#28224
- 媒体报道：OpenAI Codex has a bug that could kill your SSD in under a year（notebookcheck）
关于
关注我获取更多资讯
