OpenAI Codex 日志记录 Bug：过度的 SSD 写入与解决方法

OpenAI Codex 日志记录 Bug：过度的 SSD 写入与解决方法

OpenAI Codex 日志记录 Bug 导致过度的 SSD 磨损

A critical bug in OpenAI Codex 导致应用程序向本地 SSD 写入海量数据——可能高达数 TB。该问题源于应用程序默认启用了 trace/debug 日志记录，并使用了一个缺乏日志轮转或容量限制的无界 SQLite 数据库。

技术根本原因：无界的 SQLite Trace 日志

性能下降和磁盘消耗是由写入 SQLite 数据库的 trace 级别日志“洪水”引起的。由于日志系统没有实现轮转或大小限制，日志文件会无限增长，消耗可用磁盘空间并增加 SSD 硬件的磨损。

用户报告称，即使在应用程序闲置时，这种行为也可能发生。一位用户指出，在他们的 SQLite 日志文件上运行 VACUUM FULL 命令后，文件大小从 27GB 减少到了 73MB，这突显了当前日志记录实现的极端低效。

立即采取的解决方法与修复方案

在官方更新发布之前，用户可以采用以下技术手段来防止进一步的磁盘写入：

SQLite 触发器拦截

一种临时修复方法是创建一个 SQLite 触发器，以阻止向 logs 表进行进一步的插入。可以在 Codex 日志数据库上执行以下命令：

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

文件系统重定向

为了防止物理 SSD 磨损，一些用户建议将日志目录软链接到 tmpfs（基于 RAM 的文件系统），以确保日志被写入易失性内存而非永久存储。

社区反馈与性能担忧

除了日志记录 Bug 之外，社区还指出了 Codex 的其他几个稳定性与性能问题：

  • GPU 资源耗尽： 报告显示，在 macOS 上仅仅是让 Codex 窗口处于未隐藏状态，就可能因为渲染“spinner”加载消息而导致 100% 的 GPU 使用率。
  • Input Latency： 用户报告称，与 Claude Code 等竞争对手相比，存在明显的打字延迟。
  • 跨工具问题： 其他 AI 编程工具中也报告了类似的日志记录问题，一位用户指出 Claude Code 也会向 ~/.claude/logs 写入海量的 debug 日志。

当前状态

根据社区报告，一个修复程序已提交至 Codex 仓库（commit e98d43ac372ddf7f513c0...），预计将包含在下一个官方版本中。建议用户关注官方 GitHub 仓库以获取更新。

Sources