Codex CLI 一年悄悄写 640TB 到你的 SSD？这事我看完原 issue 倒吸一口气
事情是这样的——上周末我跟同事吃饭，他随口说他那台 M2 Mac 的 SSD 健康度掉得有点离谱，怀疑是 Xcode 缓存。我让他先别急着背锅给 Xcode，结果一查，真正的元凶居然是 Codex CLI。
回家我翻了下 GitHub 上的 issue #28224，越看越后背发凉。直接说结论：
OpenAI 官方 Codex CLI 在后台静默写 SSD 的速度，按年算大约 640 TB。
没有补丁，也没有官方修复时间。
这是个怎样的 bug
Codex CLI 在 ~/.codex/logs_2.sqlite 维护着一个本地 SQLite 日志库，里面用的是 TRACE 等级 的 logger——意思是连每一次 token 流式输出、每一次模型心跳，全都被写进数据库。
骚操作在这里：这个 logger 不读 RUST_LOG 环境变量。 也就是说，你以为按官方文档把日志级别调到 warn 就万事大吉，实际上 SQLite 这条线根本不鸟你的配置，照写不误。
社区实测的写入速率：
- 流式输出时持续 5 MiB/s
- 高峰时 16 MiB/s
- 折算到一年，大约 640 TB
对比一下：一块普通消费级 NVMe SSD 的写入寿命（TBW）通常在 300~600 TB 区间。也就是说，你只要每天正常用 Codex，不到 12 个月就能把 SSD 写穿。
为什么 OpenAI 没动
issue 4 月 10 日就有人提了，6 月 14 日有人再次系统性复现并升级了严重程度。截至今天，没有 patch，没有 ETA。
我个人猜测原因：这个 SQLite 日志在内部应该是用来做"对话回放 + 错误归因"的工具，删了影响产品分析。但用户这边的 SSD 不是他们的成本——典型的 PM 视角错位。
临时自救方案
Linux / macOS 用户可以把日志重定向到内存盘：
# 备份现有库
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
# 软链到 tmpfs (Linux) 或临时目录 (macOS)
ln -s /tmp/codex_logs.sqlite ~/.codex/logs_2.sqlite
这样所有写入都进 RAM，重启清空，对 SSD 零负担。Windows 暂时没有等效方案，只能等官方修。
顺手插一个连带踩坑点
写这篇之前我顺着 issue 区往下翻，发现 Codex 自己还有个 #9356 号老 bug 特别离谱：
你问 Codex “怎么升级你自己”，它会非常自信地告诉你跑 npm install -g codex。
但这条命令是错的。
codex 这个无 scope 的包是 2012 年的某个无关项目，跟 OpenAI 半毛钱关系都没有，装上之后静默存在、毫无功能。正确的包名是 @openai/codex，多一个组织前缀。
我当时看完笑出声——一个 AI 编程工具，被自己用户问"怎么升级"的时候教错命令，让人去装一个 2012 年的僵尸包……这画面太行为艺术了。
最后说两句
这两件事放一起看，挺有意思的：
一边是三星刚刚把 Codex 推给全员，OpenAI 自己公布的全球周活 500 万、韩国半年涨 800%。
另一边是 Codex CLI 在用户磁盘上无声写穿 SSD，issue 挂了两个月没人修。
用 AI 工具的红利时代是真的，但"早期产品"的属性也是真的。 跑得太快的产品，bug 也会跑得太快。
如果你已经在用 Codex CLI：
du -sh ~/.codex/logs_2.sqlite看下日志库现在多大- macOS 用户可以顺手
smartctl -a /dev/disk0 | grep -i written看下 SSD 总写入量心里有个数 - 不放心就上面那段
ln -s先做了
评论区聊聊你 SSD 现在多少 TBW 了？我自己刚查完，已经 87 TB，比预期高出一大截，估计 Codex 贡献了不止一半。
Sources
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
7
0- 0
已为社区贡献4条内容
所有评论(0)