警惕！官方称已修复，但 Codex 仍在悄悄"写穿"Mac 的 SSD

📝

Codex 日志 bug 修复后，Mac 桌面端仍在造成异常磁盘写入，已有用户 SSD 提前报废。本文分析 Mac 为何尤其危险、如何自查和止血。

来源：微信公众号「知识姬 Mina」

Codex 还在悄悄写穿 Mac 的 SSD。

官方说修了。可一堆 Mac 用户这几天还在喊卡顿、重启、甚至硬盘直接挂了。

📖 背景回顾

几周前，Codex 有个日志 bug 被捅出来：默认 TRACE 级别疯狂往本地 SQLite 写，有人 21 天写了 37TB，年化能到 640TB。普通 1TB 消费级 SSD 标称寿命也就 600TBW 左右，照那个速度跑不满一年就可能把寿命写穿。OpenAI 很快推了 0.142 版本，把写入砍了大半，GitHub 上相关 issue 也陆续关掉。很多人以为这事过去了。

结果昨天社区上又炸了。有人发帖说 Mac 上的 Codex App 还在造成持续 I/O 飙高，关掉程序后系统依然卡，必须重启才恢复。更狠的是，已经有用户报告 SSD 提前报废——有人 Samsung 盘写到 60TB 就挂（标称 600TB），有人用了半年 NVMe 直接死，数据丢了一部分。这些不全是旧 bug 残留，Mac 桌面端似乎还在触发额外写入。

很多人以为 AI 工具只是烧算力和电。实际上它还能烧你的硬盘寿命。

🍎 为什么 Mac 上尤其危险

MacBook 的 SSD 是焊死的。坏了只能整机送修或者换板，成本直接上万。

Codex 桌面端在后台会留下 code_sign_clone 目录，有人清理前看到涨到 12GB；同时触发系统进程 mds_stores、syspolicyd、kernel_task 一起狂写。有用户用 IORegistry 测过，空闲状态两分钟还能写 400 多 MB。

这不是 CPU 或内存吃满那么简单。关掉 Codex 后卡顿还在，说明 I/O 队列或者缓存没清干净。有人让 Codex 自己诊断，它也只说”excessive I/O and graphics work”，解释不了为什么重启才好。

理论上，日志级别降到 INFO 后写入应该大幅下降。可桌面端和 CLI 的路径不完全一样，加上 JetBrains 插件、Xcode 衍生数据这些联动，实际放大效果还在。有人测到写速短时冲到 300-400MB/s，系统直接卡死。

CLI 用户反馈相对好一点。图形界面那套进程树更重。

🔍 官方修完为什么还有人中招

6 月下旬那波修复主要针对 SQLite 的 TRACE 轰炸，确实把核心日志写入砍下去了。但后续还有 issue 在报：Mac App 启动后残留的克隆目录、系统索引服务被拖着写、GPU/WindowServer 空转发热。有人 7 月还在测到异常磁盘活动。

用户报告里出现过几种典型情况：

用一会儿就系统整体变慢，关掉也不恢复
硬盘写入量异常飙升，SMART 数据难看
极少数直接物理损坏，需要换盘

这些案例是不是 100% 由 Codex 单独造成，社区里有争论。有人觉得是本来就高强度用盘，Codex 只是加速器；也有人拿着写前写后的数据对比，认为关联很强。目前没有官方新声明说”彻底解决”。

🛠 现在怎么自查和止血

确认版本

桌面端去 About 里确认版本，CLI 用：

1	codex --version

或直接更新：

1	npm install -g @openai/codex@latest

监控写入量

macOS 装 smartmontools：

1	brew install smartmontools

查看 SMART 数据：

1	sudo smartctl -a /dev/disk0

看 Data Units Written 或 Total_LBAs_Written。

对比平时不用 Codex 时的增量。如果开着 Codex 就明显跳，就有问题。

临时止血措施

尽量用 CLI 而不是桌面 App
把 ~/.codex/logs_2.sqlite 相关文件清掉或重定向
用完就彻底退出，别挂后台
定期看 Activity Monitor 的磁盘写入排行，把 Codex 相关进程盯紧
极端情况下，先别长时间挂着跑大型任务

💭 小结

SSD 寿命是预算制，不是到点就炸。写多了只是加速老化，真正挂掉还要看主控和颗粒运气。但焊死的 Mac 盘一旦出问题，维修窗口和数据风险都更大。

用 AI 工具的时候，记得顺手看一眼磁盘写入。别等它真坏了才后悔。