北京
两周前我差点白白掏钱换笔记本电池。风扇全天满速嘶吼，硬盘灯像闪光灯一样狂闪，系统活动监视器死死咬住一个我每天都信任的进程：codex。后来发现硬件完全正常——真正受伤的是我那块固态硬盘，它默默吞下了Codex CLI内部一个日志缺陷产生的数TB写入量。
这事不是传闻，也不是极端的边缘案例。它是个有记录、可量化的漏洞，至少从2026年4月起就潜伏在Codex CLI里，持续一整年写入的数据量能超过绝大多数消费级固态硬盘全寿命标注。好在现在有真正的修复、有可靠绕行方案，还有一段五分钟的检查法，能看出你的硬盘是否已经挨了刀。
如果你赶时间，这里先划重点：Codex CLI的本地日志系统一直向一个SQLite文件里以每年约640 TB的节奏写入——这远远超出主流1 TB消费SSD的标称寿命。OpenAI已在Codex CLI v0.142.0（当前含在v0.142.2中）放出修复，能削减约85%写入量。你可以用现成工具查清硬盘究竟承担了多少额外写入。另外，那个“把日志文件通过软链接指向/tmp”的流传方案默认根本保护不了macOS——而且几乎没人提起这一茬。
问题到底出在哪？Codex CLI将本地诊断日志保存在~/.codex/logs_2.sqlite以及配套的-wal和-shm文件里。工具写日志很正常，要害是它出厂带的日志级别：全局TRACE级默认，记录一切，包括原始WebSocket和SSE负载、tokio-tungstenite等依赖库的内部交互噪音，还有重复的OpenTelemetry镜像事件。这些东西对开发者几无用处，而且几秒钟内就会被数据库自动清理。但插入和删除操作却每时每刻都在发生——只要Codex在跑，一秒不停。
一位名为1996fanrui的开发者最先在2026年6月14日的GitHub issue #28224里给出量化数据。他发现磁盘活动异常后一路追到SQLite日志，测算出在21天开机期间主硬盘被写入了约37 TB。按年折算大约640 TB——相当于一块1 TB固态硬盘被全盘重写640次。这还不是第一份报告。早在4月10日，issue #17320就标记了同样现象，测到普通流式传输时持续写入约5 MiB/s，峰值冲到16 MiB/s。只是那会儿OpenAI还没把线索串起来。
更隐蔽的地方在于：SQLite数据库文件的逻辑大小几乎不会膨胀，所以用常规磁盘工具扫一眼根本看不出异样。真正的写入量全躲在频繁的小块擦写和系统级写放大里，只有用iostat或smartctl之类工具拉出设备写入量数字才会暴露异常。
OpenAI的反应路径很清晰：6月14日报告量化后，团队确认根因，随即在v0.142.0里把默认日志级别从TRACE压到INFO，并彻底禁用了WebSocket载荷记录和重复遥测镜像。7月发布的v0.142.2版稳固了这一变更，实测写入量削减约85%。也就是说，一台先前年写640 TB的机器，修复后年写入量回到100 TB附近——离普通消费盘寿命线远了一大截。
关于流传中的“把logs_2.sqlite软链接到/tmp”的绕行方案，它在macOS上默认不奏效。macOS/tmp是内存文件系统，而SQLite的-wal机制在内存盘上会导致异常回滚和性能骤跌，而且重启后日志就消失，做排查时等于自断线索。如果非要手动作临时缓解，比较妥当的做法是把日志路径挂到一个机械盘或外置盘上，但最佳选择仍是升级到修复版本并运行一次SSD寿命检查。
检查操作很简单：在终端用smartctl -a /dev/disk0打出SMART数据，找到Total_LBAs_Written字段，观察数值是否远高于同期同配置机器。或者用iostat追踪写流量，修复前空闲状态下不应有持续高写入。
事件本身没有新算法、新模型那么惹眼，但对每天跑着Codex CLI的工程师而言，它直愣愣告诉你：一个看似不起眼的TRACE级日志，能悄悄啃掉你硬盘里最贵的磨损预算。修复已经就位，花五分钟查一下，不光是为自己的数据，也是为让那块勤恳的SSD不至于提前退休。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
