Codex 也犯低级错误：TRACE 日志进生产，用户 SSD 21 天写入 37TB

OpenAI Codex 出了个低级错误：把开发调试用的 TRACE 日志，直接带进了生产环境。

一位用户报告，他的 SSD 在 21 天内写入了约 37TB，Codex 是主要写入来源。

按这个速率算，一年 640TB。你的 SSD 写入寿命大概 600TB——一年不到，硬盘接近报废。

低级在哪

日志分级别：TRACE 是最详细的调试日志，只应该在开发环境开。生产环境默认用 INFO 或 ERROR。

Codex 呢？TRACE 占了 70.7%。

一个每月 200 美金、300 万周活的产品，默认开着最详细的调试日志。这不是设计选择，这是忘了关。

10,000 倍的写入放大

更离谱的是写入放大。

数据库里只保留了 50 万行数据，但 SQLite 的自增计数器跑了 55 亿次。

50 万 vs 55 亿，10,000 倍的差距。

日志在疯狂地插入、删除、再插入。你的 SSD 在做无用功，但写入寿命是实打实地消耗。

日志文件膨胀 300 倍

另一位开发者发现，他的 Codex 数据库本身只有 115MB，但配套的日志文件膨胀到了 65GB。

200MB 变成 65GB，300 倍。

正常情况下，日志文件会定期合并清理。但 Codex 的写入速度太快，清理跟不上，文件像肿瘤一样越长越大。

WSL 用户更惨

Windows WSL2 用户报告，打开 Codex 后 C 盘活跃度直接 100%，持续读写 2-3 GB/s。系统卡到不能用。

可能是内存不够用，SSD 被当成了临时内存在疯狂交换。

最讽刺的部分

codex doctor 命令——那个帮你检查健康状态的工具——对几十 GB 的膨胀日志视而不见，告诉你：

"databases healthy"

硬盘在燃烧，它说一切正常。

修了，但还没完全修

4 月社区首次定位问题，5-6 月多个用户报告类似情况，有人实测 21 天 37TB。

6 月 22 日，OpenAI 合并了两个修复 PR。从定位到修复，约两个月。据报告修复后日志量减少 85%。

但修复还没进稳定版。 当前最新版 0.141.0 不包含修复。你得等下一个稳定版。

你现在能做的

检查一下你的 Codex 目录：

du -sh ~/.codex*

超过几个 GB？中招了。

清理方法：

# 先完全退出 Codex
pkill -f codex

# 删除膨胀的日志文件
find ~/.codex -name "*.sqlite-wal" -delete

Reddit 用户清理后说："删了 3 个文件，GPT-5.5 变成了一头猛兽。"

不是模型变强了，是 SSD 终于能呼吸了。

我的看法

Codex 是强工具，GPT-5.5 编码能力 SOTA 级别。

但 TRACE 日志进生产环境，这种低级错误不该出现在 200 美金/月的产品里。

修复已经在 main 分支，等稳定版更新吧。现在能做的就是定期检查、手动清理。

#Codex #OpenAI #SSD #Bug #避坑指南 #开发者工具