隐形 SSD 杀手OpenAI Codex CLI 日志 Bug 深度解析与自查指南一个看似无害的 SQLite 日志文件可能正在悄悄“烧穿”你的固态硬盘。⚡️ 一键临时止血先退出 Codex 再执行如果你只想立刻阻止 Codex 继续磨损你的 SSD先完全退出 Codex 进程然后将下面整段命令粘贴到终端执行适用于 macOS / LinuxDB$HOME/.codex/logs_2.sqlite# 1. 备份带时间戳cp$DB$DB.bak.$(date%Y%m%d%H%M%S)cp$DB-wal$DB-wal.bak.$(date%Y%m%d%H%M%S)2/dev/null||truecp$DB-shm$DB-shm.bak.$(date%Y%m%d%H%M%S)2/dev/null||true# 2. 创建拦截触发器静默丢弃所有新日志写入sqlite3$DBCREATE TRIGGER IF NOT EXISTS codex_block_logs_insert BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;# 3. 清空并截断 WAL 文件sqlite3$DBPRAGMA wal_checkpoint(TRUNCATE);echo止血完成。如果返回 0|0|0说明 WAL 已清空。Windows 用户请参考正文中的手动步骤或使用 WSL 执行上述命令。执行完毕后Codex 将不再向 logs 表写入任何新日志。这仅是本地临时方案会彻底禁用该数据库的日志记录但能立刻停止对 SSD 的异常磨损。后续请务必升级到官方修复版本并删除触发器命令见正文。下面我们详细拆解这个 Bug 的来龙去脉、危害原理以及完整的手动修复与验证过程。最近OpenAI 的终端 AI 编程工具Codex CLI被曝出一个堪称“硬件杀手”级别的 Bug它会在后台以每秒约 5MB的速度疯狂写入日志而表面文件大小却毫无异常。按此速率一年累计写入量可达 640TB足以在不到一年内耗尽一块普通消费级 NVMe 固态硬盘的全部写入寿命。更令人不安的是这个问题自今年 4 月起就已存在直到近期才因社区用户的精确量化报告而引爆舆论。今天这篇文章带你彻底搞懂这个 Bug 的来龙去脉、为什么它能骗过那么多开发者以及你该如何立刻自查并紧急止血。一、Bug 从何而来——被遗忘的 TRACE 级别Codex CLI 在运行时会将诊断日志记录到本地的一个 SQLite 数据库文件~/.codex/logs_2.sqlite中。问题的根源在于该日志系统被硬编码为 TRACE 级别。TRACE 是日志体系中最为详尽的等级它会事无巨细地记录几乎所有底层事件原始的 WebSocket 数据包、系统文件如passwd、ld.so.cache的打开事件、内部状态变更等等。据分析这个设置是在某个 PR 中为方便内部调试而引入的却在未做任何调整的情况下直接推送给了所有终端用户。更糟糕的是Codex完全忽略了标准环境变量RUST_LOG这意味着用户没有任何简单的官方途径来调低日志级别只能眼睁睁看着它疯狂写盘。二、为什么你很难察觉到——“文件不大但路已跑烂”当听到“疯狂写盘”时很多人的第一反应是去查看文件大小。结果发现文件才几百 MB好像没事日志行数没涨好像没事磁盘剩余空间没少好像也没事这正是该 Bug 最阴险的地方。Codex 的日志系统采用的不是简单的追加写入而是一个持续「写入 → 删除 → 再写入」的循环模式每分钟执行数万次 INSERT 和 DELETE 操作。表面上数据库文件大小和记录行数保持稳定但在这平静的表象之下SSD 的实际写入量TBWTotal Bytes Written正在飞速累积。打个比方文件大小好比停车场里此刻停了多少辆车。TBW则是这条路上从早到晚一共跑过了多少辆车。一个程序反复写入、删除、整理数据库的 WALWrite-Ahead Log预写日志最后文件可能还是那几百 MB但 SSD 的闪存颗粒已经被反复擦写了无数轮。SQLite 的 WAL 机制还会造成写入放大——每次事务不仅要写主数据库还要写 WAL 文件和回滚日志进一步加剧了磨损。衡量一下这个写入量的实际意义一块典型的 1TB 消费级 NVMe SSD其 TBW 额定值通常在 600TB 左右。Codex 以 5MB/s 基线写入峰值可达 16MB/s一年下来足以让它寿终正寝。而 SSD 寿命耗尽的表现往往不是缓慢降速而是可能突然变为只读模式或彻底无法识别导致数据丢失。三、立刻自查你的 SSD 中招了吗我让 Codex 自查了一次自己的 SQLite 日志写盘 bug。提示词很简单“帮我检查 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘如果中招先备份再用 SQLite trigger 拦截 logs 表 insert并 checkpoint/truncate WAL最后采样确认 MAX(id) 和 WAL 不再增长。”无论你是否感觉到了系统变慢只要近期高频使用过 Codex CLI都建议立即做一次快速诊断。macOS / Linux 检测命令在终端中依次执行DB$HOME/.codex/logs_2.sqlite# 1. 查看文件大小及 WAL 文件状态ls-lh$DB$DB-wal2/dev/null# 2. 查看 logs 表当前总行数(COUNT) 与 历史最大写入序号(MAX(id))sqlite3$DBSELECT COUNT(*), MAX(id) FROM logs;# 3. 按日志级别分类统计看 TRACE 是否占大头sqlite3$DB SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC; Windows 路径与检测方法Windows 下的路径类似一般为%USERPROFILE%\.codex\logs_2.sqlite。你可以用类似逻辑在 WSL 或安装了sqlite3的环境下进行检查或使用 GUI 工具打开数据库执行上述 SQL。重点观察信号隔30秒再查一次连续执行两次对比变化。如果看到以下现象请高度警惕COUNT(*)基本没变但MAX(id)持续上涨logs_2.sqlite-wal文件的修改时间和大小不断变化TRACE级别的日志数量占绝对大头日志内容中包含大量 SSE / WebSocket / streaming 等高频事件关键解读COUNT(*)是当前还剩多少行MAX(id)是曾经写到第几条。如果行数稳定但 ID 一直涨说明系统在背后不断“写入一批 → 删除一批 → 再写入”这正是本 Bug 的典型特征。四、紧急止血本地临时修复方案在 OpenAI 官方修复完全推送到你使用的版本之前可以手动“阉割”掉这个有害的日志写入。操作前请务必完整退出 Codex 进程。1. 备份日志数据库以防万一DB$HOME/.codex/logs_2.sqlitecp$DB$DB.bak.$(date%Y%m%d%H%M%S)cp$DB-wal$DB-wal.bak.$(date%Y%m%d%H%M%S)2/dev/null||truecp$DB-shm$DB-shm.bak.$(date%Y%m%d%H%M%S)2/dev/null||true2. 创建拦截触发器静默丢弃所有新日志写入sqlite3$HOME/.codex/logs_2.sqlite CREATE TRIGGER IF NOT EXISTS codex_block_logs_insert BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;这个触发器会让任何尝试插入logs表的操作都无提示地被忽略。3. 清理并截断 WAL 文件sqlite3$HOME/.codex/logs_2.sqlitePRAGMA wal_checkpoint(TRUNCATE);正常情况下会返回0|0|0表示 WAL 已被成功清空。4. 再次采样验证效果DB$HOME/.codex/logs_2.sqlitesqlite3$DBSELECT COUNT(*), MAX(id) FROM logs;stat$DB-wal2/dev/nullsleep30sqlite3$DBSELECT COUNT(*), MAX(id) FROM logs;stat$DB-wal2/dev/null如果 30 秒后MAX(id)不再增长WAL 文件未再更新则说明止血生效。如何恢复日志写入如果后续排查需要日志可随时删除触发器sqlite3$HOME/.codex/logs_2.sqliteDROP TRIGGER IF EXISTS codex_block_logs_insert;注意这个临时方案会让 Codex 此后完全不写 logs 表。若你需要利用本地诊断日志请慎用优先升级到已修复的官方版本。五、官方修复与社区迂回方案OpenAI 响应较快已通过合并 PR #29432 和 #29457将 SQLite 日志默认级别从 TRACE 降至INFO据称可减少约 85% 的日志写入量。所有用户应尽快升级到最新版 Codex CLI。在补丁推送期间社区还摸索出一个更彻底的应急方案将logs_2.sqlite软链接到/tmp。因为多数 Linux/macOS 系统的/tmp挂载为 tmpfs内存文件系统写入不会触碰物理硬盘且该文件不包含用户对话数据重启丢失无任何影响。不过这仍是权宜之计根治还得靠官方升级。六、更深层的警示当 AI 助手拥有“写盘自由”这次事件暴露的远不止是一个配置失误。它提醒我们随着 AI 编码助手深度嵌入日常开发环境它们获得的系统权限和数据访问范围正在急剧扩大。一个普通的代码编辑器不会以每秒 5MB 的速度向你的磁盘写入数据但一个需要监听文件变化、建立代码索引、记录 WebSocket 通信的 AI 代理实际上已成为系统中最活跃的进程之一。尤其在 Codex 的/goal模式下它拥有完整的文件系统读写权限和自主决策能力。一个日志级别的配置错误就足以让一个旨在提升效率的工具悄无声息地变成硬件寿命的终结者。这为所有 AI 工具开发者敲响了警钟权限越大对底层资源尤其是不可再生的硬件寿命的敬畏之心就应当越强。最后再次提醒每一位 Codex 重度用户现在就花 2 分钟自查一下你的 SSD 可能正在被看不见的“日志风暴”磨损。别等数据丢失再后悔。
