# OpenAI Codex 静默往用户 SSD 年化写入 640 TB，已逼近消费级硬盘额定寿命

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-06-25T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/40696
- 原文：https://yage.ai/share/codex-ssd-write-bug-20260623.html

## 摘要

OpenAI Codex CLI 被发现长期在后台往本地 SQLite 日志库疯狂写入数据，21 天累积 37 TB，年化约 640 TB。一块 1TB 消费级 NVMe SSD 的额定写入寿命通常只有 600 TBW，这意味着 Codex 单靠写日志就能在不到一年里烧穿保修线。问题出在日志级别默认设成了 TRACE，连打开系统文件、WebSocket...

## 推荐理由

Codex 静默烧 SSD 这件事，有具体数字、有根因定位、有修复状态追踪、有自检命令，信息密度很高。Hacker News 头版加 The Register 跟进，形成跨源信号。没打更高是因为修复已经推了，影响面在收窄，但「修了不说」这个点本身又拉回一些关注度。

## 锐评

这件事最值得从业者留意的地方，不是 OpenAI 又出 bug，而是我们日常检查磁盘的那套习惯完全失效了。du、df、Finder 看的是文件系统逻辑大小，Codex 的 SQLite 日志库一边狂写一边回收空间，文件体积纹丝不动，只有 SMART 计数器能读出物理写入量。报告者 Rui Fan 实测 21 天写入 37 TB，年化 640 TB，而一块 1TB 消费级 SSD 的额定写入寿命通常就 600 TBW。4 月 10 日就有人贴出了 strace 里 pwrite64 刷屏的证据，但每个看到 issue 的人都用 du 扫一眼，觉得文件不大、磁盘没满，就没当回事，直到 6 月 22 日登上 Hacker News 前排才引爆。

根因是日志级别默认设成了 TRACE，连打开系统文件和 WebSocket 原始帧都原封不动记下来，而且 Codex 自己的默认值会绕过用户设的 RUST_LOG 环境变量。0.142.0 合并了修复，报告者反馈能砍掉约 85% 的写入，年化降到 32 TB 左右，回到正常水平。但 Windows 桌面包在修复合并后仍然复现，第三项关键修复还在 0.143.0 里没发布。

正文没披露 OpenAI 内部为什么把默认级别设成 TRACE，也没解释为什么 4 月的报告没被及时升级。600 TBW 是保修值不是硬边界，很多盘超了还能用，截至发稿也没有公开的因这个 bug 实际烧坏硬盘的案例。但这件事提醒我们：本地 agent 常驻后台之后，磁盘写入会变成一个需要主动监控的指标，不能只靠文件大小和剩余空间来判断。