OpenAI Codex 日志 Bug：SQLite 写入量年化可达 640TB

OpenAI Codex 上周被报出一个相当夸张的 bug：本地反馈日志的 SQLite 数据库默认按 TRACE 级别记录几乎所有内部事件，导致 SSD 写入量按年化能到 640TB。这篇整理一下问题是怎么被发现的、根因在哪、官方修了什么，以及社区在等修复期间用的临时方案。

问题是怎么被发现的

GitHub 用户 1996fanrui 在 issue #28224 里贴出了自己机器的实测数据：运行 21 天后，主 SSD 累计写入约 37TB，排查发现主要写入源是 Codex 的本地反馈日志数据库：

text

~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm

按这个速率换算，一年大概是 640TB —— 对一块 1TB 的盘来说相当于全盘写入 640 次。不少消费级 SSD 的标称寿命在 600TBW 左右，意味着这个 bug 理论上能在一年内把一块新盘的寿命写穿。

写入放大有多夸张

issue 里给出的快照很说明问题：当前数据库只保留了约 50 万行数据，但 SQLite 的 AUTOINCREMENT 计数器已经推进到了 55 亿。也就是说历史上写入过的行数是当前保留行数的上万倍——数据不断被插入、写 WAL、再被裁剪删除，循环往复。

按日志级别拆分保留下来的内容也能看出问题所在：

级别	占比
TRACE	70.7%
INFO	25.7%
DEBUG	3.0%
WARN	0.6%

光是 codex_api::endpoint::responses_websocket 这一个 TRACE 级别的 target，就占了保留日志体积的一半以上，加上 OpenTelemetry 的镜像日志（codex_otel.log_only、codex_otel.trace_safe），两者合计能解释 96% 的日志体积。

根因

代码里反馈日志的 sink 是这样初始化的：

rust

Targets::new().with_default(Level::TRACE)

也就是给所有 target 设置了全局 TRACE 默认级别，连依赖库内部日志和原始 WebSocket/SSE 报文都被完整落盘，而不是只记录 Codex 自己关心的事件摘要。

官方的修复

issue 在 6 月 22 日被作者关闭，原因是两个 PR 已合并，据反馈能减少约 85% 的日志量：

不过 issue 关闭后,后续仍有多个新 issue 报告类似现象（如 #29556、#29570、#29588），有用户反馈升级到 rust-v0.142.0 之后 macOS/Windows 上仍能观察到持续的 SQLite 写入，只是速率比修复前低了不少。

等修复期间，社区给的临时方案

在官方修复合并前，有用户写了脚本来缓解问题，核心思路是定期触发 WAL checkpoint 把日志文件裁剪掉：

bash

# 对 logs_2.sqlite 做一次 WAL checkpoint truncate，Codex 运行中也可执行
sqlite3 ~/.codex/logs_2.sqlite "PRAGMA wal_checkpoint(TRUNCATE);"

更激进的做法是直接用触发器拦截写入（Windows 下的例子）：

powershell

# 阻止新日志写入 logs 表（可逆）
sqlite3 "$env:USERPROFILE\.codex\logs_2.sqlite" "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

# 需要时撤销，恢复日志功能
sqlite3 "$env:USERPROFILE\.codex\logs_2.sqlite" "DROP TRIGGER IF EXISTS block_log_inserts;"

这类方案的代价是反馈日志功能被整体关掉，如果之后要提交 /feedback，得先把触发器删掉。

影响范围有多大

issue 评论区里有人按 Codex 周活用户量做了个粗略估算：以约 300 万周活用户、假设其中一部分受影响、按 SSD 写入成本 0.13 美元/TBW 折算，即便只有 5% 的用户达到原始报告里的写入强度，造成的 SSD 寿命损耗也在百万美元量级；如果平均强度更高，估算会到千万美元级别。考虑到很多设备（尤其笔记本）的存储是焊死在主板上的，实际损失可能要按整机成本而不是单纯换盘成本来算。

现状

截至目前，官方的两个修复 PR 已经合并，日志量据称减少了 85%，但写入放大的核心模式（插入后立刻裁剪）并没有被完全消除，仍有用户在升级后的版本上观察到持续写入。如果你长期开着 Codex CLI 或 Desktop，建议先确认自己的 Codex 版本是否已经包含 rust-v0.142.0 之后的修复，并留意 ~/.codex/logs_2.sqlite* 的体积变化。

字节笔记本