这两天一直在研究这个话题，踩了几个坑，把遇到的东西整理成文，供有需要的朋友参考。
你买的 SSD 保质写入量 600TB。Codex 一年能帮你写掉 640TB。而 OpenAI 从 2025 年就知道这事，至今没有回应。
一、事件回顾：当你信任的 AI 工具在偷偷毁掉你的硬盘
2026 年 6 月 22 日，GitHub Issue #28224 登上 Hacker News 首页。
这个 Issue 揭露了一个惊人的事实：OpenAI Codex 的本地 SQLite 日志系统，默认以全局 TRACE 级别运行，持续将 WebSocket/SSE 的完整原始负载写入本地 SSD。
数据触目惊心：
指标数值21 天写入量~37 TB年化写入量~640 TB/年消费级 1TB SSD 典型耐久度~600 TBW结论不到一年即可耗尽一块 SSD
更荒谬的是，这些写入中 70.7% 是 TRACE 级别的噪声——包括 WebSocket 连接的原始字节流、inotify 文件事件的 128,764 条重复记录、tokio-tungstenite 内部调试日志。
说白了：你的 SSD 在被海量的 ld.so.cache 文件被打开了、locale.alias 被读取了 这类信息反复擦写。
时间线更让人愤怒：
这个问题的历史能够追溯到至少 2025 年。从 Issue #17320 到 #28224，共 11 个关联 Issue，跨越一年以上。用户从"Codex 空闲时 I/O 异常"报告到"WAL 无限增长"再到"日志过大导致桌面端启动失败"，报告越来越具体。
而 OpenAI 做了什么？
什么都没做。
没有官方回复。没有紧急修复。甚至社区贡献者 1996fanrui 和 Nicolas0315 尝试提交 PR 时，GitHub 返回：
does not have the correct permissions to execute CreatePullRequest
连社区帮你修都不让。
二、技术深潜：一个 TRACE 是怎么毁掉 SSD 的
2.1 写入放大的多米诺骨牌
问题根源在 Rust 的 tracing 框架中一行看似无害的配置：
Targets::new().with_default(Level::TRACE)
这一行代码意味着：所有日志 target——包括 Codex 自身的、OpenTelemetry SDK 的、tokio 运行时的、hyper HTTP 客户端的——全部以 TRACE 级别写入 SQLite。
但真正的杀手不是日志数量，而是 SQLite WAL（Write-Ahead Log）的写入放大效应。
实测数据显示：15 秒内，SQLite 的保留行数没变（681,774 行），但最大行 ID 从 5,003,347,015 增长到了 5,003,383,226——15 秒插入了约 36,211 行，接着被修剪删除。
这就是写入放大的本质：插入 → 索引 → 写入 WAL → 修剪 → 再插入。每一条日志数据都被多次写入闪存单元。对于 SSD 来说，这不是"写入了 37TB 数据"，而是"闪存单元经历了远超 37TB 的擦写循环"。
2.2 日志污染的具体构成
来看看这些 TRACE 日志到底在写什么：
来源级别大小占比codex_api::endpoint::responses_websocketTRACE527.4 MiB50.9%codex_otel.log_onlyINFO141.2 MiB13.6%codex_otel.trace_safeINFO121.2 MiB11.7%logTRACE97.4 MiB9.4%codex_client::transportTRACE60.1 MiB5.8%
光过滤掉 TRACE + codex_otel.* 就能消除 ~96% 的写入。 修复方案在技术上极其简单——社区的 PR 只改了几行代码：
// 从
Targets::new().with_default(Level::TRACE)
// 改为
warn,codex_api=info,codex_app_server=info,codex_core=info,codex_mcp=info,codex_state=info
2.3 这不是个"bug"，这是系统设计的缺失
严格来说，这不是一个代码缺陷——代码确实按设计运行了。问题是这个设计本身就没考虑过后果。
一个面向开发者的工具，默认将所有内部通信的完整内容（包括 prompt、response、token 流）写入本地文件却不设任何上限，这暴露了三个层次的系统性问题：
1. 工程层面：没有日志量上限、没有磁盘写入监控、没有降级机制
2. 测试层面：显然没有人跑过多天的"正常使用"场景测试
3. 组织层面：11 个 Issue 一年多没人管，说明反馈到修复的链路已经断裂
三、这不是孤例——AI 工具正在系统性地侵蚀用户控制权
Codex 日志 Bug 单独看是一个糟糕的工程实践。但如果把近期事件串起来，一个令人不安的模式浮现了：
3.1 Claude 要验你的身份证
就在 Codex Bug 登上 HN 的同一天，Anthropic 的"Claude 身份验证"以 753 points、621 comments 霸榜 HN #16。
Anthropic 要求用户上传政府签发的照片 ID + 实时自拍，由第三方 Persona 处理。官方说这是"负责任地使用强大技术"。但社区的反应说明了一切：621 条评论——这是 HN 近期最高的讨论量之一。
同时，HN #8（224 pts）的文章标题直白得刺眼：“There is minimal downside to switching to open models”（切换到开源模型几乎没有缺点）。
3.2 三件事的共振
把这三件事放在一起看：
事件本质用户失去的Codex TB 日志 Bug闭源工具在用户不知情的情况下消耗硬件寿命对自己硬件的控制权Claude 身份验证使用 AI 需要向上提交身份匿名使用的权利"切换到开源模型"热榜社区在用脚投票对闭源生态的信任
这不是三个独立事件，而是一个趋势的三个侧面：闭源 AI 工具正在以"负责任"、"更强大"的名义，系统性地从用户手中夺取控制权。
而用户的反抗来得比预期更快。HN 上越来越多人说：“我以前感觉开源模型性能差一点能够忍，现在感觉性能差一点也值得。”
3.3 从 cURL 罢工到 Codex Bug：信任崩塌的时间线
如果把时间线拉长：
- 2026 年 4 月：cURL 创始人 Daniel Stenberg 发起"Summer of Bliss"罢工，抗议 AI 工具无节制爬取、生成垃圾代码、污染开源生态
- 2026 年 5 月：GitHub 10000+ 木马仓库被曝光，AI 生成的恶意代码利用平台审查漏洞传播
- 2026 年 6 月（今天）：Codex 被发现默默烧毁 SSD；Claude 动手强制身份验证；HN 首页喊出"切换到开源模型几乎没有缺点"
四、对未来的三个判断
判断 1：Codex 的声誉修复将极其难。 这不是"有个 bug 修了就好"的问题。一年多不回应 + 阻止社区 PR 的组合拳，已经不是在伤害用户体验，而是在伤害用户对"OpenAI 是否在乎开发者利益"这个根本问题的信心。
判断 2：开源 AI 工具将进入"信任红利期"。 当闭源工具每次更新都可能带来新的"惊喜"（身份验证、日志炸弹、数据收集），开源工具的"可审计性"从一个 nice-to-have 变成了 must-have。Continue.dev、Aider、Cline 等项目可能迎来增长。
判断 3：AI 工具的"责任边界"将成为下一个监管焦点。 如果一个工具在用户不知情的情况下加速了硬件损耗、收集了超出合理范围的数据、或强制改变了使用条件——这些行为在法律和伦理上的边界在哪里？这不是技术问题，是治理问题。
五、开发者该怎么应对？
对于 Codex 用户（立即行动）
1. 检查你的 SSD 写入量。 Windows 用 CrystalDiskInfo，macOS 用 smartctl -a disk0，Linux 用 nvme smart-log /dev/nvme0。如果 Total Bytes Written 异常高，Codex 很可能是罪魁祸首。
2. 立即部署 WAL 截断脚本。 社区提供了临时方案——定期执行 sqlite3 ~/.codex/logs_2.sqlite "PRAGMA wal_checkpoint(TRUNCATE);" 并设为 crontab 每 15 分钟运行一次。
3. 监控 ~/.codex/ 目录大小。 如果持续增长，在 OpenAI 修复之前，考虑停用 Codex 或切换到替代方案。
对于选择 AI 工具的技术团队
1. 把"可审计性"纳入选型标准。 不要只看基准分数和功能列表。问自己：如果这个工具有问题，我能自己见到问题在哪吗？我能自己修吗？对于一个你每天运行 8 小时的开发者工具，这个问题的答案比 benchmark 分数更重要。
2. 建立"AI 工具健康检查"流程。 定期检查 AI 工具的资源消耗——不仅仅是 CPU/内存，还有磁盘 I/O、网络流量、存储增长。
3. 认真评估开源替代。 Continue.dev、Aider、Cline、Roo Code 等开源 AI 编程工具已经能覆盖大部分使用场景。性能差距在缩小，但信任差距在扩大。
对于做 AI 工具的产品团队
这个事件是一个反面教材：对于一个开发者工具来说，"不伤害"比"更强大"重要得多。 你的用户每天把他们的机器、代码、生产力交给你。如果你连最基础的"不会烧毁硬盘"都做不到，之前积累的所有信任会在一夜之间清零。
你怎么看？
Codex 这个 Bug 的荒诞程度，放在其他任何一个普通软件上，产品经理的工位可能已经被愤怒的用户包围了。但因为是 AI 工具，因为挂着 OpenAI 的牌子，因为"AI 总是有些小问题"——它就这么漂了一年多。
这引出了几个值得讨论的问题：
- 如果你发现你用的 AI 工具在后台默默做你完全不知道的事，你的第一反应是"正常"还是"不可接受"？
- 闭源 AI 工具的"信任溢价"还能撑多久？开源替代达到性能临界点的那一天，会发生什么？
- 作为一个每天烧掉你 SSD 寿命的工具，OpenAI 该承担什么责任？退款？补偿？还是至少——一句公开道歉？
数据
就写这么多吧，内容比较基础，适合入门回顾。有补充的地方欢迎留言一起完善。
评论 (0)
暂无评论