OpenAI Codex CLI 曝出严重 Bug：日志写入耗尽 SSD 寿命

6月22日消息，OpenAI 的 Codex CLI 近期出现一个离谱的 Bug——写入日志太猛，直接把 SSD 的寿命“烧”没了。

早在6月14日，就有用户报告了这一问题。一个ID为 1996fanrui 的 GitHub 用户发现，自己的设备长期磁盘占用异常高。

追查下来，罪魁祸首竟然是 Codex CLI 在疯狂往本地 SQLite 数据库里写诊断日志。

惊人数据：21 天写入 37TB

这位用户实测的数据相当吓人：设备连续运行21天，累计产生了 37TB 的磁盘写入量。

按这个速度推算，全年写入总量差不多 640TB。而目前主流1TB消费级SSD的标定 TBW（总写入字节数）普遍只有 600TB。

换句话说，如果持续运行这个工具，不到一年就能把 SSD 的耐久度彻底耗尽。

问题根源：全局 TRACE 日志级别

问题出在哪儿？根源是 Codex 内置的 SQLite 日志采集组件，默认启用了 全局 TRACE 级别。

TRACE 是日志系统中粒度最细的模式。程序会把 WebSocket 原始传输数据包、系统文件读写等所有底层行为全部记录下来，连读取 passwd、ld.so.cache 这些系统文件的常规操作都照单全收。

统计显示，大约 71% 的 TRACE 日志其实都是底层冗余信息，对普通用户完全没用。

更棘手的问题：忽略环境变量

更要命的是，这个工具直接忽略了标准的 RUST_LOG 环境变量。所以用户没法通过常规方式降低日志输出级别。

临时解决方案（Linux / macOS）

好在 Linux 和 macOS 平台有一个临时解决方案：创建一个符号链接，把 ~/.codex/logs_2.sqlite 指向 /tmp/ 目录。这样所有日志写入操作就会转移到内存里。

注意：这个日志文件只存底层运行记录，不会涉及用户对话数据。而且设备重启后日志丢失，也不会影响 Codex CLI 正常运行。

《夸克》非常好用的免费AI浏览器

下载APP查看