Codex Bug 修复

警告！！你的 SSD（固态硬盘） 可能正在被 Codex 偷偷写废（附自查 + 一键止血）

最近 X 上炸了个 Codex 的大 bug：高强度用 Codex 的小伙伴注意了，你的硬盘可能正在被偷偷「核打击」👇。我一开始也没太当回事，直到自己查了一下——好家伙，真给哥中招了，而且不轻。
先别慌，这篇文章带你三步搞定这个问题：
搞清它在干嘛 → 一句话自查 → 让 Codex 自己止血（修复）。下面每一步我都在自己电脑上跑通了。

这 bug 到底在干啥
说人话：Codex 在跑流式任务、长任务的时候，会以极高频率往本地一个日志库 ~/.codex/logs_2.sqlite 里狂写 TRACE 日志（就是最啰嗦、最没用的那种调试日志）。
先给不太熟的小伙伴补一句：SSD 就是现在新电脑里普遍用的那块「固态硬盘」，你的系统、软件、文件基本都装在它上面，比老式机械硬盘快很多。但它有个软肋——每个存储格子能被「擦写」的次数是有限的，写到一定量就会老化、变慢，严重了直接坏。所以「被疯狂写」对它来说，是实打实地折寿，极大的减少了使用时间。
如果只是写一两条日志本来没事，但Codex APP是「写了删、删了写」地疯狂折腾，写入量大得离谱。这么造下去，SSD 真有可能被提前写废。
这也不是危言耸听——OpenAI 官方 GitHub 上一堆人报了同样的问题，有人实测照这速度一年能写出 ~640TB；更坑的是你手动设 RUST_LOG 都拦不住它。文件一旦涨到 200MB 以上，还可能直接把 Codex 拖崩。

01　先自查：你中招了吗
不用自己敲命令。最省事的办法——把下面这段直接发给 Codex，让它只读检查一下（💬 只读、不动你任何东西）：

帮我检查一下 Codex 的日志库 ~/.codex/logs_2.sqlite（Windows 在 C:\Users\你的用户名\.codex\ 下）是不是中了「狂写 TRACE 日志磨 SSD」的 bug。只读检查、先别改，告诉我四件事：①文件现在多大；②logs 表各个 level 各多少行、TRACE 占比多少；③自增 id 的最大值（看历史一共写进过多少行）；④盯 30 秒看新增多少行、估算每秒写入速率。

就这么发给它👇

把自查这段话直接丢给 Codex 就行
等一会儿它会给你一份「体检报告」，我这台长这样：

我这台的体检结果：322MB、TRACE 占 6 成、历史写过 2500 多万行
看报告盯这三个数就够了：
① 文件多大：我这台 322MB，正常顶多几十兆；
② TRACE 占比：我这 63%，大半都是这种没用的啰嗦日志,建议直接删除！；
③ 历史 id：我这已经到 2500 多万——意思是这阵子它已经写进又删掉了两千五百万条，还在以每秒十几条的速度接着造。

⚠️ 文件已经超过 200MB 的小伙伴尤其要当回事：除了费盘，还可能让 Codex 启动变慢、甚至崩给你看。

02　中招了？让 Codex 自己止血
最符合咱们「能让 AI 干就不自己动手」的路子——把这段发给它：

确认中招了，帮我止血：用 SQLite 触发器让 logs 表的新写入静默跳过（RAISE IGNORE），别删任何数据、要可逆。装好后盯 30 秒确认 max(id) 不再增长，给我修复前后的对比。

它会给自己装一个「拦截器」（一个可逆的 SQLite 触发器），让这些垃圾日志的写入被直接忽略，但你的数据一条都不删。装完它自己盯 30 秒确认不写了，给你前后对比👇

止血前后：写入从十几条/秒直接掉到 0，数据一条没少
你看，写入速率从十几条每秒直接掉到 0，文件大小、各级别行数一点没变。我这台就这么止住了。
03　想自己动手 / 想撤销（进阶）
嫌发 prompt 慢、想直接上命令的，对着那个库执行这一行就行（建 1 个触发器）：
CREATE TRIGGER codex_logs_block_new_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;
哪天官方把 bug 修好了，想还原也是一行：
DROP TRIGGER IF EXISTS codex_logs_block_new_inserts;
⚠️ 还有件事别忽略：止血只是让它「不再写」，那 300 多 MB 的旧文件还占着地方。想彻底清掉，得先退出 Codex，再删掉 logs_2.sqlite（连同旁边的 -wal、-shm 两个文件）——Codex 下次启动会自己重建一个干净的，你的聊天记录不在这个文件里、不会丢。日常嫌麻烦的话，留着触发器止血就够了。
这 bug 官方迟早会发补丁，但在补丁来之前，花一分钟自己把血止住，硬盘要紧，保护好自己的电脑！！

PS:需要GPT plus的可以看看 GPTplus充值