Codex 的日志记录消耗 SSD 寿命？OpenAI 已修复

Bug 信息

好消息，OpenAI 已在 Codex 0.142.0 版本中修复了这个问题，可以放心使用。

最近，Codex 凭借其强大的功能和丝滑的体验，周活跃用户已经突破了 500 万 大关。越来越多的开发者和极客都已经把它当成了日常高频使用的得力助手。

不过，随着使用人数的增加，有用户反馈，在某些流式输出或自动化任务场景下，Codex 会持续向本地磁盘写入 TRACE 级别的日志。

GitHUb 的 ISSUE 上声称该 BUG 可能会产生 640GB/年 的写入，这对于消费级 SSD 来说是致命的。对于目前主流的 1TB 或 2TB 消费级固态硬盘（标称寿命通常在 600TBW ~ 1200TBW）来说，可以说是非常严重。

而且，正因为现在 AI 浪潮空前火热，全球对高带宽、高性能存储的需求集中爆发，导致现在的 SSD 固态硬盘价格一路上涨，存储成本变得相当昂贵，尤其是 mac 设备的硬盘无法更换。在这种寸土寸金的时期，我们对硬盘的每一度磨损、每一 G 空间都不得不更加精打细算。

如果你使用的是 Linux 或 Mac 系统，可以直接通过终端跑两行命令看看情况。

首先，看看日志文件的大小：

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

然后，统计一下日志的写入级别：

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

如何判断：
如果查询结果中，TRACE 级别的日志占了绝大多数，并且 logs_2.sqlite 文件体积比较大，那就说明 Codex 确实在后台认真地记录着无关紧要的追踪信息。

参考数据：
我的文件大小为 468MB：

1 2	> ls -lh ~/.codex/logs_2.sqlite Jun 23 -rw-r--r--@ 1 mro staff 468M

> sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC"
TRACE|39961
INFO|39919
DEBUG|7307
WARN|177

可以看到 TRACE|39961 占了接近一半的数据，确实存在所说的问题，主要是目前 OpenAI 官方尚未做出修复的回应。

OpenAI 已经修复这个问题了，不需要操作了

这里提供比较激进、但也最直接的临时方案：给日志表加一个 SQLite 触发器，让新的日志写入被忽略，毕竟这个文件里只有诊断日志，没有对话历史。

执行前建议先退出 Codex，并备份日志数据库：

1	cp ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak

然后执行：

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

设置完成后，新的日志记录会被拦截，从而减少后续写入。

需要注意的是，这个方法会影响 Codex 后续生成诊断日志。如果你之后需要向官方反馈问题，或者担心未来版本兼容性，可以先不要使用这个方案，改用定期清理的方式。

如何恢复

如果想要恢复的话就是删除这个 trigger 。先退出 Codex，再执行：

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

执行后可以检查是否还存在：

1	sqlite3 ~/.codex/logs_2.sqlite ".schema block_log_inserts"

如果没有输出，说明已经删除成功。

也可以用这个命令查看当前所有 trigger：

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

GitHub ISSUE 中的数据是比较夸张的，Codex 的这个日志问题并没有网传的那么吓人，但也感谢 OpenAI 完成了 BUG 的修复，祝大家用 Codex 敲代码愉快！