你有没有发现，明明没怎么用 Codex，硬盘灯却一直在闪？

不是错觉。Codex 有个 bug，会在后台疯狂往硬盘写日志，连你设了 RUST_LOG=warn 都拦不住。命令行、桌面端、VSCode 插件，全中招。这事在 OpenAI 的 issue 区从 4 月挂到现在。

先说怎么自查，30 秒搞定。

打开终端，看一眼日志文件多大：

ls -lh ~/.codex/logs_2.sqlite*

再看看里面都是些什么日志：

sqlite3 ~/.codex/logs_2.sqlite \
"SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC;"

如果 TRACE 那一行的数量远超其他，或者 -wal 文件涨到了好几个 G，你就是中招了。

我自己机器上查出来：库 600 多 MB，七万多条 TRACE，占七成。inotify 事件、websocket 包、tokio 内部状态，全给我记下来了，没一条我用得上。

为什么文件不大，危害却不小？

注意了，文件大小骗人。SQLite 跑在 WAL 模式下，新数据先进 -wal 文件，再合并回主库。Codex 一边全速插，一边删旧的，行数看着不涨，但 WAL 一直在刷盘。实测流式输出的时候，每秒往盘上写 5 到 16 MB。

按这个速度，一年能写六百多 TB。普通消费级 SSD 也就六百 TB 的写入寿命，等于一年写废一块。

好了，说治法。两种，从稳到狠。

第一种，搬到内存里。 最推荐，改动小。

先把 Codex 完全退掉，然后：

rm ~/.codex/logs_2.sqlite*
ln -s /tmp/codex_logs.sqlite ~/.codex/logs_2.sqlite

/tmp 在 macOS 和 Linux 上大多是内存盘，日志写进去不碰你的固态，重启自动清掉。这个库只有诊断日志，没有对话记录，丢了不心疼。

第二种，加触发器直接堵死写入。 更彻底，但是个硬手段。

sqlite3 ~/.codex/logs_2.sqlite \
"CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

这条的意思是：给 logs 表加个「插入前」触发器，每次插入都用 RAISE(IGNORE) 悄悄丢掉，不报错，Codex 那边也察觉不到。

装完验证一下，确认触发器在：

sqlite3 ~/.codex/logs_2.sqlite "SELECT name FROM sqlite_master WHERE type='trigger';"

再测一条插入，看是不是真被吞了：

sqlite3 ~/.codex/logs_2.sqlite \
"INSERT INTO logs (ts, ts_nanos, level, target, estimated_bytes) VALUES (0,0,'TEST','check',0); SELECT changes;"

返回 0 就对了，这条没写进去。

踩坑提醒：

加触发器前一定把 Codex 完全退干净——命令行、桌面端、VSCode 插件、任何残留进程，全关。不然有进程占着文件，你改不动。

还有，这俩都是堵漏，不是官方修复。说白了就是把本地日志关了。等 OpenAI 把日志级别的开关修好，触发器用这条删掉：

sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_log_inserts;"

我自己跑下来，搬内存这招最省事，治标又不影响用。重度用户优先选它。

硬盘灯终于不闪了，机器也清静了。你也去查一下自己的吧。