福建
你有没有发现，明明没怎么用 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;"
我自己跑下来，搬内存这招最省事，治标又不影响用。重度用户优先选它。
硬盘灯终于不闪了，机器也清静了。你也去查一下自己的吧。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
