如果你正在使用 Codex CLI、桌面版或 VSCode 插件，最近却感觉电脑变慢、SSD 空间莫名缩水，先别急着换硬件。问题可能不是设备老化，而是一个被忽视的日志文件在后台疯狂写入。
一个日志文件如何变成硬盘杀手
有 Reddit 用户发现，Codex 后台持续以约 5MB/s 的速度写盘，峰值可达 16MB/s。按这个速率，连续运行 21 天就能在主 SSD 上留下 37TB 写入量，年化约 640TB。消费级 1TB SSD 的标称寿命通常在 600TBW 左右，这意味着一年内就可能被磨到保修上限；如果是 256GB 的 QLC 固态盘，40 多天就可能击穿标称写入寿命。
更麻烦的是隐蔽性。日志文件表面只有几百 MB 到 1GB，但内部在不断删除旧记录、插入新记录，实际闪存写入远大于文件体积，形成典型的写入放大效应。这也解释了为什么用户很难从文件大小上察觉异常。
根因：写死的 TRACE 日志级别
社区深挖后发现，Codex 的日志模块在 Rust 代码里将全局日志级别硬编码为 TRACE。TRACE 是日志体系中最细粒度的一级，WebSocket 数据包、文件系统事件、遥测记录、tokio 异步运行时内部状态，全都会被写入 SQLite 数据库。更令人头疼的是，这个设置完全无视 RUST_LOG 环境变量，即使用户手动设置 RUST_LOG=warn，日志路径依然我行我素。
受影响产品覆盖 Codex CLI、Desktop 和 VSCode 插件，Linux/macOS 是重灾区，Windows 与 WSL 同样无法幸免。从今年 4 月开始，GitHub 上陆续出现相关 Issue；直到 6 月 14 日，Issue #28224 用“21 天 37TB”的铁证引发社区热议。用户们开始自救：有人用 SQLite 触发器拦截插入，有人把日志文件软链到内存盘，有人干脆把整个 .codex 目录移到机械硬盘上。
官方修复：写入量降了 85%，但没归零
6 月 23 日，OpenAI 工程师 jif-oai 合并多个修复 PR，随 Codex CLI 0.142.0 版本发布：PR #29432 不再持久化完整 WebSocket payload，PR #29457 过滤噪声桥接日志和重复遥测，PR #29599 补掉另一类桥接 TRACE 事件，0.143.0 继续跟进；0.142.5 又通过 PR #30771 修补了完整 request payload 写入 trace logs 的问题。原 Issue 报告者实测，日志写入量减少了约 85%。
但 85% 不等于 100%。按他的测算，剩余写入量年化仍约 96TB，相当于从“一年烧穿”变成“六年烧穿”。对重度用户来说，这依然是需要关注的隐患。OpenAI 的响应速度值得肯定，但也提醒我们：AI 工具的本地日志策略需要更严格的默认值，不能把压力转嫁给用户的硬件。
现在可以这样自查和处理
第一步，升级到最新版本。先运行 codex --version 查看版本，如果低于 0.142.0，立即用 npm install -g @openai/codex@latest 或官方脚本升级。特别提醒：Codex Desktop 的图形界面版本号不等于内嵌 CLI 内核版本，升级 CLI 后要确认 Desktop 内核对版本不低于 0.142.0。
第二步，确认是否仍在狂写。查看日志文件大小：ls -lh ~/.codex/logs_2.sqlite*；再用 sqlite3 查看级别分布：SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC；最后看累计插入行数：SELECT MAX(rowid) FROM logs。如果 MAX(rowid) 在几分钟内快速增长，说明还在跑旧版本内核。
第三步，清理旧日志。退出所有 Codex 进程后，把日志文件备份到 ~/.codex-log-backup/，既保留历史数据用于排查，又不让它们继续占用 SSD 空间。第四步，检查 SSD 健康度。Linux NVMe 用户可执行 sudo smartctl -a /dev/nvme0 | grep "Data Units Written"，若写入量已接近标称 TBW，就要考虑更换硬盘或调整使用习惯。
不想手动敲命令，也可以让 Codex 自己检查：给它一段提示词，让它先诊断 ~/.codex/logs_2.sqlite 是否存在高频 TRACE 写入，确认后备份文件组、创建 BEFORE INSERT 触发器拦截新插入、执行 WAL checkpoint 截断，再复查 MAX(rowid) 和 WAL 大小是否停止增长。实际检查中，Codex 在 60 秒内发现约 397 条 TRACE，数据库累计 ID 约 40 万，实际只保留约 4.2 万行，正是“持续写入、持续淘汰”的特征；处理后 MAX(id) 和总行数不再增长，WAL 保持 0 字节。建议处理后继续观察两周，每天看一次 MAX(rowid) 和 WAL 大小，如果重新快速增长，就让 Codex 再次检查。
别让 AI 工具成为 SSD 杀手
这次事件给所有 AI 工具用户提了个醒：本地运行的 Agent、IDE 插件和后台服务，日志策略可能远比想象中激进。不要因为“只是日志”就放松警惕，写入放大和隐藏日志会在不知不觉中消耗硬件寿命。建议定期关注版本更新和磁盘写入量，对高频写盘的工具保持敏感。
如果你正在用 Codex，现在就去看一眼版本号，低于 0.142.0 立刻升级。你的 SSD 不该为软件的日志策略买单。