AI 编程助手可能正在“偷偷写爆”你的 SSD：Codex 这个问题，给所有开发者提了个醒

最近技术圈传出一个挺吓人的说法：

OpenAI Codex 可能会疯狂写入本地 SSD，一年写入量外推高达 640TB。

乍一看，这像是那种典型的标题党。

一个 AI 编程工具，不就是帮你写代码、改代码、跑命令吗？

怎么还能跟 SSD 寿命扯上关系？

但我顺着原始出处查了一下，发现这事不是空穴来风。

更准确地说：

“Codex 一定会写爆所有人的 SSD”这个说法夸张了。

但：

Codex 曾经确实存在本地日志写入过于激进的问题，而且官方仓库里已经有人提交 issue，后续也合并了修复 PR。

这件事真正值得关注的地方，不只是一个 bug。

而是它提醒我们：

AI 编程工具已经不再是一个简单插件，它正在变成长期运行在本机上的开发基础设施。

既然是基础设施，就必须定期升级。

一、这件事的原始出处在哪里？

这次传播最广的说法，源头主要来自 OpenAI 官方 Codex 仓库里的一个 GitHub Issue：

Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance #28224

这个 issue 里，用户报告说，Codex 会持续向本地这些 SQLite 日志文件写入数据：

其中最关键的一句话是：

该用户称自己的机器在约 21 天 uptime 后，主 SSD 写入量大约 37TB。

如果按这个速度年化外推，大约就是 640TB/year。

这就是“Codex 一年写 640TB SSD”的来源。

注意，这里有一个非常重要的细节：

640TB 不是官方说每个人都会写这么多，也不是跑满一年后的实测结果，而是某个高强度使用场景下，根据 21 天数据做的年化外推。

所以，不能把它理解成：

只要你装了 Codex，你的 SSD 一年就会被写废。

更准确的说法应该是：

在某些高强度使用、长时间运行、流式任务较多的场景下，旧版本 Codex 的本地日志写入可能异常偏高，确实存在影响 SSD 写入寿命和系统性能的风险。

二、问题不是“AI 太聪明”，而是“日志太吵”

这次问题的核心，不是模型本身在疯狂训练，也不是 AI 在偷上传你的代码。

它主要指向一个很传统的软件工程问题：

日志写得太多了。

Codex 会在本地保存一些反馈和诊断日志，底层用的是 SQLite。

正常来说，软件写日志很正常。

问题在于，有用户发现，Codex 在流式输出、WebSocket event、OpenTelemetry mirror events 等场景下，会产生大量本地日志记录。

更早的 GitHub Issue #17320 里，已经有人报告：

在流式输出期间，Codex 的 app-server 会持续写入：

观察到的写入速度约为 5 MiB/s，甚至最高看到约 16 MiB/s。

这就不太正常了。

因为对普通用户来说，这些底层 TRACE 级别日志，大多数时候没有直接价值。

它们不是你的代码，不是你的项目文件，也不是你主动保存的内容。

但它们会实打实写到硬盘上。

最麻烦的是，SQLite 的 WAL 文件、insert-and-prune、索引、checkpoint、文件系统层面的写放大叠加起来，最终看到的 SSD 写入量可能远高于日志文件表面大小。

这也是很多人容易误判的地方：

你看文件夹可能只有几百 MB、1GB。

但实际 SSD 累计写入，可能已经是几十 GB、几百 GB，甚至更多。

三、官方其实已经动手修了

在 #28224 里，提交者后来更新说，2026 年 6 月 22 日，有两个相关 PR 已经合并：

一个是：

#29432 Stop logging every Responses WebSocket event

简单说，就是不要再把每个成功的 Responses WebSocket payload 都按 TRACE 级别写进本地日志。

另一个是：

#29457 Filter noisy targets from persistent logs

简单说，就是过滤掉一些特别吵、价值不高、容易造成 SQLite insert-and-prune churn 的日志来源。

这两个修复方向很清楚：

不是完全砍掉日志。

而是让日志更克制。

这其实是一个成熟软件该做的事情：

开发阶段可以多打日志，方便定位问题；

但生产环境、用户机器上，就不能把所有底层噪声都一股脑写进本地数据库。

尤其是 AI 编程助手这种工具，一开就是一天，甚至很多人会让它在 IDE、终端、后台里长期运行。

一个小的日志策略问题，放到高频使用场景里，就可能被放大成硬盘写入问题、性能问题、风扇狂转问题、甚至应用卡顿问题。

四、这事真正给开发者的提醒：Codex 要定期升级

很多人对 AI 编程工具的使用习惯，还是停留在“插件”时代。

装上就不管了。

能用就不升级。

不报错就不看版本。

但现在的 Codex、Claude Code、Cursor、Windsurf、Copilot 这类工具，已经不是简单的编辑器插件了。

它们可能包括：

本地 CLI；

IDE extension；

后台 app-server；

日志系统；

文件监听；

终端执行；

项目索引；

远程 API 通信；

沙箱环境；

权限管理；

甚至多进程协作。

这已经接近一个小型开发平台。

既然是平台，就会有 bug。

既然高频运行，就会有性能问题。

既然跟本地文件系统、终端、代码仓库打交道，就会有安全和稳定性问题。

所以我觉得，这次 Codex 日志写入事件，最值得普通开发者记住的一句话是：

AI 编程工具，不要长期停留在旧版本。

尤其是 Codex 这种还在快速迭代的工具，最好定期升级。

不是为了追新功能。

而是为了吃到这些性能修复、日志修复、权限修复和稳定性修复。

五、普通用户要不要恐慌？

不用恐慌。

但建议你做三件事。

第一，检查一下 Codex 版本。

如果你很久没有升级过 Codex，尤其是还在使用比较早的 alpha / beta / extension 版本，建议尽快通过你当初安装的渠道升级。

可能是 npm。

可能是 Homebrew。

可能是 VS Code / Cursor 插件市场。

也可能是 GitHub Releases。

关键不是用哪种方式。

关键是：

不要装完就永远不管。

第二，检查一下本地 Codex 日志大小。

macOS / Linux 用户可以看一下：

如果你发现 logs_2.sqlite-wal 或整个 ~/.codex 目录异常大，就要注意了。

尤其是出现这些现象时：

电脑突然变卡；

风扇异常狂转；

磁盘活动时间很高；

Codex Desktop 或 IDE 变慢；

SSD 写入量异常增长。

这时候第一反应不应该是怀疑系统坏了，而是先看看 AI 编程工具有没有异常后台写入。

第三，定期重启和升级 AI 编程工具。

很多开发者电脑从不关机，IDE 一开就是十几天。

这在以前问题不大。

但现在 AI agent 工具越来越多，后台进程越来越复杂。

长期不重启、不升级、不清理，就容易积累各种奇怪问题。

我的建议是：

重度用户，每周检查一次更新；

普通用户，至少每两三周升级一次；

遇到磁盘、发热、卡顿异常，优先升级到最新稳定版；

不要盲目追 alpha，但也不要长期停留在旧版本。

六、最后说句实在话

这次事件不应该被理解成：

“Codex 不安全，别用了。”

也不应该被理解成：

“AI 编程助手会毁掉你的硬盘。”

更合理的结论是：

Codex 这类 AI 编程工具迭代很快，问题也修得很快。

但前提是：

你得升级。

你不升级，修复合并了也跟你没关系。

很多时候，开发者遇到的奇怪问题，并不是工具不行，而是自己手上跑的是一个几周前、几个月前的旧版本。

AI 时代，工具链升级会变得更重要。

以前我们定期升级浏览器，是为了安全和兼容性。

以后我们定期升级 AI 编程助手，是为了性能、稳定性、权限和本地资源安全。

所以这次 Codex 事件，我最大的建议很简单：

用 Codex 可以，但最好定期升级。

别等 SSD 写入量异常、电脑卡成 PPT、日志文件堆到几十 GB，才想起来看版本。

AI 编程工具已经是开发者的新基础设施了。

基础设施，不能长期裸奔。