Codex被曝“硬盘杀手”：一年狂写640TB，SSD直接被送走
Codex CLI就被扒出了一个史诗级bug——疯狂写日志，一年干废一块SSD。
同一个公司，一边说着“修补地球”，另一边却“烧穿硬盘”。
📊 先看数据：离谱到什么程度？
GitHub用户@1996fanrui在6月14日提交了问题反馈：他的电脑连续运行21天，主SSD被写入了约37TB数据。
换算成年化数据：约640TB/年。
什么概念？一块主流1TB消费级SSD的标称写入寿命（TBW）也就600TB左右。
也就是说，如果你重度使用Codex且放任不管，不到一年，你这块SSD的保修寿命就被Codex的日志文件写穿了。
更骚的是，这一切是静默发生的。用户打开文件管理器看，日志文件大小平平无奇，实际写入量却早已爆表。
🔍 罪魁祸首：TRACE级别的“噪音”日志
问题根源很简单，也很离谱。
Codex的SQLite日志模块默认以全局TRACE级别运行。TRACE是什么？日志系统里最“话痨”的模式，什么都记——原始WebSocket数据包、系统文件读写事件、甚至打开passwd和ld.so.cache这种常规操作，全都不放过。
统计显示，约71%的日志数据属于TRACE级别的冗余信息，对普通用户毫无诊断价值。
更要命的是，Codex直接忽略了标准的RUST_LOG环境变量，用户连“把日志关小点”这个常规操作都做不到。
💀 为什么SSD死得比想象中更快？
问题不只是文件变大，而是写入放大（Write Amplification）。
Codex的SQLite数据库每分钟执行数万次插入和删除操作。文件大小看着不大，但物理层面的写入量远超表面数值。SSD的闪存颗粒每分每秒都在被反复擦写，寿命就这么被一点点榨干了。
🛠️ 临时方案：把日志扔进内存
OpenAI至今未在更新日志中修复写入速率问题，相关Issue仍处于挂起状态。
不过Linux和macOS用户可以这样自救：
bash
# 把日志文件重定向到内存目录 ln -s /tmp/ ~/.codex/logs_2.sqlite
原理很简单：/tmp/目录通常挂在内存（tmpfs）上，写入操作不会落到SSD物理颗粒上。该文件不包含任何对话数据，重启丢了也不影响使用。
Windows用户……暂时没看到官方建议。
最新反转！OpenAI光速发布修复补丁，但问题真的解决了吗？
6月22日，也就是问题被广泛曝光的第二天，Codex v0.142.0版本火速上线，官方声称修复了日志疯狂写入的问题。
这速度，值得给OpenAI的公关团队点个赞。但仔细一看代码改动，事情好像没那么简单。
🔧 修复了什么？
根据官方更新日志和PR（Pull Request）描述，新版本的修复策略是“砍掉最高频、最低价值的日志事件”，具体包括：
- 停止记录成功的WebSocket事件。之前每个成功的WebSocket事件会产生3条本地日志记录（包括完整的payload TRACE日志、OpenTelemetry log事件和OpenTelemetry trace事件），高并发下瞬间塞满日志配额。
- 通过内置过滤器排除高频事件源，如
log、codex_otel.log_only、codex_otel.trace_safe等，不再把这些冗余信息写入本地SQLite数据库。
官方的说法是：保留必要的遥测数据供团队排查问题，但把“最吵、最没价值”那部分砍掉。理论上，这应该能显著降低写入频率，至少不会再出现“每天写超1TB”的恐怖场景。
⚠️ 但是！问题没有完全解决
如果你以为更新一下就万事大吉了，那可能高兴得太早。
蓝点网在追踪报道中指出，这个修复的核心是“降噪”而非“禁用日志”。最关键的隐患在于：新版本的默认日志级别依然是TRACE——只不过通过过滤器拦住了部分高频事件。
这意味着什么？
- 写入量会大幅下降，但不会归零。Codex团队依然在收集遥测数据，只要日志系统还在工作，SSD写入就不会停止。
- 部分用户反馈问题仍在。在GitHub Issue #28224被关闭后，一些macOS和Windows用户报告称，本地的
logs_2.sqlite和WAL缓存文件在升级后依然持续增长，高频覆盖现象没有彻底消失。
说白了，这更像是一次“打地鼠”——把最响的那几锤子按住了，但地鼠本身还没被消灭。
📌 建议
如果你是重度Codex用户，即使升级到v0.142.0，依然建议保留之前提到的临时方案：在Linux/macOS下将日志文件符号链接到/tmp/内存目录。毕竟，Trust但Verify——相信OpenAI修了，但自己动手更安心。
至于Windows用户，继续耐心等待后续补丁。毕竟，一块SSD的价格，可比OpenAI的月费贵多了。
好消息是：至少这一次，OpenAI没让人等上三个月才动手。坏消息是：这个“修复”，看起来更像是一个“缓解”。