https://codexer.com/tags/%E6%80%A7%E8%83%BD/Recent content in 性能 on CodexerHugozh-cnTue, 23 Jun 2026 09:00:00 +0800https://codexer.com/posts/2026-06-23-codex-ssd-logging-bug/Tue, 23 Jun 2026 09:00:00 +0800https://codexer.com/posts/2026-06-23-codex-ssd-logging-bug/<p>想象一个场景：你买了一台新 MacBook，装好 Codex CLI 就开始用它写代码。每天开着终端，Codex 在后台帮你补全、重构、调试。三个月后，你发现电脑越来越慢，打开 Activity Monitor 一看，磁盘写入量已经超过了 150TB。翻遍进程列表，凶手正是那个你最信任的 AI 编程助手。</p> <p>这不是虚构。2026 年 6 月 14 日，GitHub 用户 1996fanrui 在 Codex 仓库提交了一个 Issue，标题简洁但触目惊心：「Codex is writing 640 TB/year to my SSD」。</p> <h2 id="一个被忽视的诊断日志">一个被忽视的「诊断日志」</h2> <p>问题的核心藏在 <code>~/.codex/logs_2.sqlite</code> 这个不起眼的文件里。</p> <p>Codex CLI 内部有一个日志子系统，它把运行期间的所有事件，包括每一次工具调用、每一段 WebSocket 消息体的完整内容、甚至每次对 <code>/etc/passwd</code> 和 <code>ld.so.cache</code> 的平凡文件访问，全部写入一个本地的 SQLite 数据库。</p> <p>关键不在于「记录了日志」，而在于<strong>以什么级别记录</strong>。</p> <p>Codex 的 SQLite 日志 sink 默认运行在 TRACE 级别。在传统日志体系里，TRACE 是最低层级，用于调试极其底层的代码执行细节。正常发布的软件产品要么默认关闭 TRACE，要么只在用户主动开启时才启用。但 Codex 的日志子系统不仅默认开 TRACE，而且<strong>完全忽略 <code>RUST_LOG</code> 环境变量</strong>，用户没有任何办法调低日志级别。</p> <p>更糟糕的是，根据社区分析，约 71% 的写入数据属于 TRACE 级别的噪音日志，对普通用户来说毫无意义。你花钱买的 SSD 寿命，正在被一堆你看不见也用不上的日志数据匀速消耗。</p> <h2 id="640-tb-是怎么算出来的">640 TB 是怎么算出来的</h2> <p>1996fanrui 的机器上有一块 1TB SSD。他在 21 天里积累了约 37TB 的写入量，折合每天约 1.76TB。按这个速率往下推，一年就是 640TB。</p>