Codex 史诗级大 BUG，到现在都还没修彻底

前两天在 X 上刷到一条帖子，标题挺吓人：「Codex 史诗级大 BUG」，配的话更吓人——"高强度用 Codex 的，你的磁盘可能正在遭受核打击"。说的是 Codex 长时间运行时，会疯狂往本地一个数据库文件里写日志（说白了，就是 Codex 在你电脑里记流水账的那个文件），强度高到能把消费级 SSD 写废。^[1]

发帖的人附了两个提示词，可以自己查、自己止损。

查询用：

帮我检测 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘？

如果中招了，用这个处理：

中招了就直接先备份，再用 SQLite trigger 拦截 logs 表，并 checkpoint/truncate WAL，最后采样确认 MAX(id) 和 WAL 不再增长。

这帖一出，不只在 X 上炸了，Hacker News、Reddit、十几家中外媒体跟着全上了。

卧槽这还了得！我自己也在大量用 Codex，赶紧也自己查了一下。

中招了。

结果是：我的日志文件已经 771MB，历史上往里写过1800多万行，当下只留着4万多行；一边疯狂写、一边疯狂删，来回空转了十来天，采样那十秒里，行号还在往上涨。

还好不是TB级别的数据。

同一条帖子底下，有人说刚买一个月的电脑被写进去 24 个 T，有人电脑直接热崩、卡死。我"只"被写了 700 多 MB，还好没出大事。

回头想，大概是沾了个习惯的光：我基本每一两周清一次系统，缓存、日志、备份、没用的文件和 App 顺手都收拾掉。多半是这段时间随手清理，无意中一次次把它压了下去。

发现了就得先止血。

我按第二个提示词，把文件备份了一份，然后在它上面装了个"拦截器"，往后 Codex 再想往这儿写，动作一到就被挡掉、落不了盘。 Codex 本身可以照常跑不受影响。顺手又把文件瘦了身，从 771MB 压回 372MB（爱清理的老毛病哈哈）。

这事先这样。

后来我又去社交媒体（X和小红书）找了一下相关信息，看看是怎么个事。

Codex 默认把日志开到了最啰嗦的级别，长时间运行时，把一大堆原始通信数据、心跳信号一刻不停往本地写，差不多每秒 5 MB，十几秒就能塞进去三四万条没用的日志。

别看文件大小看着涨得不快，因为它一边写一边删，可真正落到盘上的写入量，远比你看到的文件大得多。

有人连续跑了 21 天，主硬盘被写进去 37 个 T——照这速度，一年要超过 640 个 T。一块普通 1TB 的固态，标称寿命也就 600 个 T 上下，这么造，不到一年就能把质保寿命耗光，256G 的小盘更是个把月就废（我的丐版就是）。

受伤的还不止硬盘，有人说光开着 Codex，十分钟能吃掉 15 个 G 流量。

而且这不是个别系统的事，命令行、桌面客户端、VSCode 插件，Windows、Mac、Linux，全端中招。^[2]

更离谱的是：这个BUG不是才发生的。

早在4月10号，就有人在 GitHub 提了工单，标题写得明明白白：日志无视环境变量、流式运行时狂写；中间又有人重新报了一遍，标题直接标着"每年能写 640TB、快速消耗 SSD 寿命"，还是没人正经修。^[3]

发那个原始工单的人，转头自己还去 Reddit 发了个帖，标题就叫《0.142.0 并没有真正修好》：他实测，Ubuntu 上新版本还在每秒写 10 兆，折算一年还有 315 个 T；Mac、Windows 也照样复现，只是轻一些；真正的修复，得再等下一个版本。底下还有人说，自己手快去修，结果把 Codex 搞到连本地数据库都打不开了。^[4]

而几乎就在同一天（23号），OpenAI 还高调发布了一个叫 GPT-5.5-Cyber 的模型，专门用来找漏洞，号称这方面最强，能给 Linux 内核、cURL 这些全世界都在用的底层软件挖漏洞、自动写补丁。^[5]

一边是"我能给全世界找漏洞"，一边是自家产品埋着个能把用户硬盘写废的BUG。

世界果然就是个巨大的草台班子。

你要说这 BUG 多高级？根本不是，它就是个"日志开太狠、又没人节流"的基本功；一个有点经验的工程师、一次正经的发布前检查，就该拦下来。

可就是OpenAI这种顶级公司，模型更强能上发布会、能刷榜、能上头条，"日志别狂写"这种事属于小问题，不上热搜；于是工单一压就是一两个月，要不是闹到20万阅读加外媒点名，根本排不上号。

能力的天花板一直在往上顶，工程的地板，却没人扫。

更让我介意的，是官方那句"已修复"。

说是修了，社区一测，315TB 一年还在烧。

月初的时候我刚聊过这个问题：AI 最值钱的本事，就是让你以为事情办成了。^[6]

Codex 跑完任务跟你说"完成了"，你不验就信，可能是它随便糊弄的；OpenAI 说一句"已修复，升级最新版"，你不测就信，可能它只修掉了一半。

这是病，得治。

模型的能力一年翻几番，可"做完了""修好了"这句话的含金量，却在悄悄贬值——因为越来越多的"完成"，用户都不会去做验证（可能是因为没时间精力，也可能是因为看不懂，反正就这么遗留下来了）。

到头来，还得用户自己搞定。

这类 BUG 最阴的地方，是它默默不报错，不会跳出来告诉你"我正在烧你的盘"——你只觉得电脑一天比一天卡、一天比一天烫，等哪天去查，几十个 T 已经写进去、寿命已经白耗了。

我昨天还在写，把一件长活交给 AI 之前，得先想清楚拿什么验它，这回 Codex 算个现成的反面教材——连做这工具的公司自己，都在最基本的地方漏掉了那道检查。

评论区有句话说得挺好：很多人以为 agent 时代最贵的是 token，后来才发现，最贵的是失控。^[7]

我这次是侥幸，有随手清理的习惯，又赶上看到那条帖子，及时按住了，下次不一定有这运气。

所以真正提醒我的，不是 Codex 这一个 bug，而是那句老话：别轻信一句"做完了""已修复"。工具能给全世界找漏洞，可盯着你自己那块盘的，还得是你自己。

附：怀疑自己中招了，怎么办（完整自查和修复网上已有人整理得很全，见下方注释，这里只挑最关键的）

自查：让 Codex 帮你看 ~/.codex/logs_2.sqlite 是不是在高频写盘、那种调试日志占不占大头。

止损，三选一：

一是在这个库上装个"拦截器"挡掉后续写入（我用的这招，零损耗，但会停掉诊断日志）

二是把日志软链到内存盘，写内存不写盘 /tmp

三是没命令行基础的，直接挪到机械盘。

然后等官方版本更新，第一时间更新版本。

参考资料：

[1] @Hickerzed（@HickerMoledao）：《Codex 史诗级大 BUG》，X，2026 年 6 月 22 日，https://x.com/HickerMoledao/status/2069111296910671960。

[2] 小红书用户：《Codex 严重磁盘狂写 Bug：现象、危害、排查》，小红书，2026 年 6 月，http://xhslink.com/o/82wrgZ82GPa。

[3] openai/codex：《Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG》（Issue #17320），GitHub，2026 年 4 月 10 日，https://github.com/openai/codex/issues/17320；又见 openai/codex：《Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance》（Issue #28224），GitHub，2026 年 6 月 14 日，https://github.com/openai/codex/issues/28224。

[4] u/原始报告者：《Update: Codex SQLite logging issue is not fully fixed in 0.142.0》，Reddit r/OpenAI，2026 年 6 月。

[5] OpenAI：《Introducing GPT-5.5》，OpenAI，2026 年 6 月 23 日，https://openai.com/index/introducing-gpt-5-5/。

[6] 陆离：《AI 最贵的智商税，是让你以为事情已经办成了》，陆离来信 Vol.016，2026 年 6 月 9 日。

[7] @mgowtham76：评论于 @Hicker_Moledao 帖文，X，2026 年 6 月 23 日。