警惕！Codex 日志 Bug 曝光：你的 SSD 寿命可能正在被默默消耗

Bug 信息

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

不过，随着使用人数的增加，有用户反馈，在某些流式输出或自动化任务场景下，会以大约 5MB/s 的速度向本地磁盘写入诊断日志。

X 上甚至有人说这个 Bug 每年会产生 640TB 的写入量，用不了一年就能把消费级 SSD 直接干废。其实大家不必过度焦虑，这个说法有些夸张了。

例如，如果按每天高强度使用 8 小时、每年 250 个工作日计算：

5 MB/s × 3600 秒 × 8 小时 × 250 天 ≈ 36 TB/年，即便是 24 小时不间断也是约为 150+ TB

这个量并不算小，但也没有到一年写废 SSD 的程度。对于目前主流的 1TB 或 2TB 消费级固态硬盘（标称寿命通常在 600TBW ~ 1200TBW）来说，一年大概只会多消耗 3% 到 5% 的寿命。

所以，你的硬盘绝对不会轻易罢工。

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

而且，这些大量生成的 TRACE 级别的日志，对我们日常使用并没有实际帮助。既然是无意义的损耗，顺手把它优化掉自然是更好的选择。

1分钟自查：你中招了吗？

如果你使用的是 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 官方尚未做出修复的回应。

三个轻松优化的实用技巧

为了让我们的电脑运行得更清爽，这里提供三个行之有效的优化小方案，大家可以根据自己的喜好任选其一：

方案一：一劳永逸（推荐：直接在数据库拦截）

比较激进、但也最直接的临时方案：给日志表加一个 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';"

方案二：优雅变通（软链到系统的内存盘）

如果你希望保留日志功能，但不希望它占用昂贵的固态硬盘写入，可以把文件软链接到系统的内存盘（/tmp 一般挂载为 tmpfs）。这样它就会在内存里进行读写，每次重启电脑就会自动清空，干干净净。

执行命令：

1 2	mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite

注：适合 Linux 用户的方法，macOS 是挂载到 /private/tmp 位于 SSD 中。

方案三：佛系应对（交给机械硬盘来抗）

如果你有非系统盘，并且不介意日志读写变慢，也可以把日志文件迁移到其他磁盘，降低系统 SSD 的写入压力。

总结

虽然 Codex 的这个日志问题并没有网传的那么吓人，但在存储器件价格高企的今天，花个一两分钟优化一下，给你的固态硬盘减减负，依然是个非常明智的习惯。祝大家用 Codex 敲代码愉快！