135
www.e7ai.com
135
周末，Codex 社区炸了。
原因是一个被挂了四个月的 bug 终于被翻出来：Codex CLI 在流式传输和自动化任务的时候，以 5M/s 的速度持续往磁盘写日志。一年下来大约 640TB——足以把一块消费级固态硬盘的写入寿命耗干。
而且它不挑版本。CLI、桌面 App、VSCode 插件全中招。
罪魁是 ~/.codex/logs_2.sqlite。这个文件里 70% 以上是 TRACE 级别的日志——什么 inotify 打开了 ld.so.cache、websocket 收了个包、tokio 内部状态——全给你怼进 SQLite。
更阴间的是它一边插一边删：15 秒插进去三万六千行，文件大小看着没怎么涨，可底下的 WAL 一直在刷盘。你盯着文件大小觉得才几百兆没事，其实写入量早就上天了。
GitHub 上已经有不少 issue 在反馈。有人晒了数据：机器开机跑了 21 天，主盘总写入量多了 37TB。排查下来，主要的持续写入者就是 Codex 的 SQLite 日志。按这速度外推，一年 640TB。一块 1TB 的消费级固态硬盘官方标称写入寿命也就 600TBW 上下——一年就能把质保寿命耗完。
有人算了笔账：256G 的 QLC 固态可能只能撑一个半月。
端午这几天没怎么用 Codex，就挂着让它跑几个自动化任务。查了一下：
ls -lh ~/.codex/logs_2.sqlite
文件不到 200MB——看着还好。但跑了这个查询：
秦始黄 OP
tssqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC"
TRACE 占了 70% 以上。几天没怎么用，实际写入量好几个 G。
评论区一片吐槽。有人说"我电脑配置不低怎么越用越卡，原来在这儿等着我"。Codex 用久了卡顿、切会话要等好几秒、插件切换都跟着卡——很可能都是这玩意儿在背后磨盘。
最暴力的：直接拿 SQLite 触发器把日志写入掐死。反正这文件里只有诊断日志，没有你的对话历史——删了、屏蔽了都不心疼：
sqlite3 ~/.codex/logs_2.sqlite “CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;”
温和一点的：把这个文件软链到内存盘（tmpfs），让它在内存里折腾，不碰你的固态硬盘，重启自动清空：
mv /.codex/logs_2.sqlite/.codex/logs_2.sqlite.bak
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite
有机械盘的：把文件挪到机械盘上，机械盘耐写，磨就磨吧。
但这些都只是 workaround。真正要修的是 OpenAI——给 SQLite sink 老老实实接上 RUST_LOG 的过滤就完事了。GitHub issue 里网友连补丁思路都写好了。可惜从四月挂到现在，官方一个回应都没有。
这个 bug 让我想起上篇文章写的一个判断：AI 人才正在从大厂流向原生公司。但工具链的质量控制呢？
Codex 的核心能力很强——多 Agent 协作、代码生成、自动化任务——但一个 SQLite 日志问题被晾了四个月，说明工程团队对基础质量问题的关注度不够。这不是"小 bug"——这是在物理层面消耗用户的硬件资产。
反过来看，这类问题在开源社区根本活不过一周——PR 早来了。但 Codex 的代码不是开源的，你只能等官方修复。
这不是说 Codex 不行。我是 Codex 的重度用户，每天用它跑任务。但这个 bug 是一个提醒：选择 AI 工具链的时候，功能强大和基础质量稳定是两回事。一个能帮你自动生成代码的工具，同时也在后台每秒写入 5MB 的无用日志——这两件事并不矛盾。
趁还没磨穿，自己先打个补丁吧。世界果然是个巨大的草台班子。
