OpenAI Codex 被曝严重 Bug：每年默默写入 640TB，你的 SSD 正在被"烧穿"

6 月 22 日，一个 GitHub Issue 登上了 Hacker News 首页，把 OpenAI Codex 推到了风口浪尖。

事情是这样的：有用户发现自己的 SSD 写入量异常飙升，排查后发现罪魁祸首是 Codex 在后台默默写入的一个 SQLite 日志数据库。21 天内写入了 37TB 数据，年化超过 640TB——而对于一块标称耐久度 600TBW 的主流 1TB 消费级 SSD 来说，这意味着不到一年就会被 Codex 单独"烧穿"。

到底发生了什么？

问题出在 Codex 的本地诊断日志系统上。Codex 会在 ~/.codex/ 目录下持续写入三个 SQLite 相关文件：logs_2.sqlite、logs_2.sqlite-wal 和 logs_2.sqlite-shm。

表面上看，数据库文件本身并不大——当前保留了约 68 万行日志，估算内容约 1GB。但问题不在文件大小，而在于写放大（Write Amplification）。

在 15 秒的观测窗口内，数据库插入了约 36,211 行新记录，但留存行数却几乎没有变化。这意味着 Codex 在持续执行「写入 → 索引 → 记录 WAL → 再清理」的死循环——大量日志被写入后立即删除，但对磁盘的物理写入已经实际发生，无法撤销。

根因：一个默认值酿成大祸

经过社区开发者分析，根因非常明确：Codex 的 SQLite 反馈日志默认以全局 TRACE 级别运行。

TRACE 是日志系统中最详细、频率最高的级别，通常只在开发调试阶段短暂启用。而 Codex 把它设为了生产环境的全局默认值。

从保留日志的内容分布来看： - TRACE 级别日志占留存字节的 70.7%，充斥着 tokio-tungstenite、inotify、hyper_util 等底层依赖的 TRACE 级输出 - OpenTelemetry 镜像遥测日志占 25.3% - 两者合计构成了 96% 的磁盘写入负担

最大的单一写入源是 codex_api::endpoint::responses_websocket 的 TRACE 日志，占 527.4 MiB——记录的是原始 WebSocket 载荷，包含用户对话内容。这不仅浪费磁盘写入，还存在隐私隐患。

影响有多严重？

这不仅是"硬盘写入多一点"的问题，而是一条递进的影响链：

第一层：性能劣化。 有用户报告 app-server 进程以 5-16 MiB/s 的速率持续写入 WAL，导致编辑器和终端明显卡顿。长时间运行后 Desktop 甚至变得不可用。

第二层：功能瘫痪。 Windows 用户发现 logs_2.sqlite 膨胀到数 GB 后，app-server 启动时 SQLite 连接池超时，直接弹出「Codex cannot access its local database」错误。用户需要手动删除 SQLite 文件才能恢复。

第三层：数据安全风险。 有用户报告当磁盘空间被日志耗尽时，Codex 在执行任务时删除了项目目录外的文件。虽然这一场景尚未被官方确认，但 /goal 模式下磁盘写满可能触发 Agent 自主清理行为的担忧确实存在。

OpenAI 的回应：修了，但没完全修

这个 Bug 最早在 4 月 10 日就以 Issue #17320 的形式被报告。到 6 月 22 日登上 HN 首页时，已有至少 7 个独立 Issue 涉及同一根因，覆盖了 CLI、Desktop、Windows、Linux 多个平台。

6 月 15 日发布的 Codex v0.141.0 确实包含了一条相关修复：「Bundled SQLite is pinned to a version containing the WAL-reset corruption fix (#27992)」。但这修复的是 WAL 损坏导致的数据库不可用，不是写入量问题。

核心根因——全局 TRACE 默认值和 INSERT-PRUNE 写放大——在任何已发布版本中都未被修改。截至 6 月 22 日，Issue #28224 仍处于 Open 状态，OpenAI 未合并任何修复，也未发表官方回应。

相比之下，同一时间段内 Codex 在功能层面保持了高频更新：Record & Replay、Chrome 扩展、Computer Use 等新功能接连推出。SQLite 日志问题在优先级排序中显然被排在了后面。

你能做什么？

在官方修复发布之前，有几个临时缓解方案：

2. 定期截断 WAL 文件
   ：执行 PRAGMA wal_checkpoint(TRUNCATE) 手动回收 WAL 空间
4. 手动清理
   ：删除 ~/.codex/logs_2.sqlite* 文件（代价是诊断日志将为空）
6. 监控写入量
   ：定期执行 du -sh ~/.codex/logs_2.sqlite* 关注文件增长

但这些方案都需要一定的技术门槛。对于非技术用户，除了等待官方修复，暂时没有零门槛的防护手段。

这件事意味着什么？

Codex 日志 Bug 看似是一个技术细节问题，但其暴露的信号值得关注：

TRACE 级别作为全局默认写入生产环境——这不是边缘 case，而是所有用户在正常使用中必然命中的路径。 从 4 月到 6 月，经过至少 7 个独立 Issue 报告，跨越多个平台，核心代码路径仍未修改。这种响应速度与 Codex 作为 OpenAI 主力开发者工具的产品定位之间存在明显落差。

在 AI 编程工具激烈竞争的当下，一个"默默烧穿用户 SSD"的 Bug 比任何功能缺失都更容易摧毁开发者信任。修复方案在技术上并不复杂——将默认日志级别从 TRACE 调整为 INFO+，加上 WAL 大小上限和自动轮转——社区 fork 已经实现。现在的问题是：OpenAI 什么时候动？