OpenAI Codex 存在一个漏洞，可能在不到一年的时间内导致您的 SSD 损坏

如果你使用OpenAI 的 Codex CLI 并让其长时间运行，你的 SSD 可能会遭受严重冲击。

一位名为 1996fanrui 的 GitHub 用户于 6 月 14 日记录了这一问题 ，此前他注意到自己的机器上磁盘活动异常频繁。经过一番排查，他发现 Codex 一直在向本地 SQLite 数据库（存储于 ~/.codex/logs_2.sqlite）持续写入诊断日志。在连续运行的 21 天内，该硬盘承受了约 37 TB 的写入量。 按年化计算，这相当于每年约 640 太字节。一款典型的 1 TB 消费级 SSD 其额定寿命约为 600 TBW——因此，如果放任此漏洞不管，它可能在不到一年的时间内就耗尽硬盘的全部保修耐用度。

罪魁祸首是一项日志配置，这恐怕是无人有意将其交付给最终用户的。Codex 的 SQLite 反馈接收器默认以全局 TRACE 级别运行——这是最嘈杂的设置。它会记录从原始 WebSocket 有效载荷到诸如打开 'passwd' 和 'ld.so.cache' 之类的普通文件系统事件等一切内容。 它还会忽略标准的 RUST_LOG 环境变量，因此无法通过明显的方式降低日志级别。大约 71% 的日志数据属于 TRACE 级别的冗余信息，至少对普通用户而言，这些信息并无实际诊断价值。

更糟糕的是写入放大效应。数据库不仅在不断增长，每分钟还会循环执行数万次插入和删除操作。其实际写入磁盘的数据量远超文件大小的表面值。

实际上，这一问题以各种形式存在已久，至少可追溯至 4 月，且全年已收到多份相关报告。OpenAI 最近的更新日志虽提及了部分 SQLite 可靠性修复，但并未解决写入速率问题。该问题至今仍悬而未决。

与此同时， Linux 和 macOS 用户可将 '~/.codex/logs_2.sqlite' 创建符号链接至 '/tmp/'，以将写入操作重定向至内存。该文件不包含任何对话数据，因此重启后丢失该文件并无大碍。