用户曝Codex高频写盘损耗磁盘并分享防护方案

背景

近期，AI 编程助手 Codex 被曝出一个严重的技术缺陷：其内部机制会导致对磁盘进行大量且高频的读写操作。这一行为不仅严重消耗了存储设备的寿命，还可能对硬件造成不可逆的物理损伤。对于像作者这样的 Codex 重度用户而言，这一问题尤为致命，因为频繁的写入操作会迅速缩短 SSD（固态硬盘）等存储介质的使用寿命。

在发现该 Bug 后，作者第一时间与 Codex 进行了交互，试图通过提示词工程（Prompt Engineering）让 AI 自动构建防护机制。然而，在验证防护效果的同时，作者也意识到 AI 自身可能存在其他未知的缺陷，这促使他开始考虑在 Claude Code (CC) 或 OpenCode 等其他替代方案中寻找更稳定的解决方案。

核心内容

作者详细记录了自己遭遇该 Bug 的过程、尝试修复的方法以及相关的技术细节：

1. 问题确认与初步应对： 作者确认自己的电脑确实受到了该 Bug 的影响。Codex 自身也评估认为，其对磁盘造成的写入压力巨大。随后，Codex 生成了一套防护代码或脚本，旨在限制或优化日志写入行为。

2. 版本修复情况： 社区中有声音指出，Codex 的 CLI（命令行界面）版本 142 已经修复了此问题。作者尝试升级至该版本，并让 Codex 分析修复的具体逻辑。然而，Codex 未能清晰解释修复原理，或者其解释存在不确定性，这使得作者对自动修复的可靠性存疑。

3. 手动防护方案： 鉴于自动修复的不确定性，作者分享了一个经过验证的、用于检测和处理该问题的提示词。该提示词的核心逻辑是利用 SQLite 的触发器（Trigger）机制来拦截日志写入。具体步骤包括：

   • 检查状态：检查 ~/.codex/logs_2.sqlite 文件是否因 TRACE 级别日志的高频写入而异常增长。
   • 数据备份：一旦确认中招，首先备份数据库文件以防数据丢失。
   • 拦截写入：使用 SQLite Trigger 拦截对 logs 表的 INSERT 操作，从而从数据库层面阻止无效日志的写入。
   • 维护存储：执行 checkpoint 和 truncate WAL（预写日志）操作，清理未提交的日志数据。
   • 验证效果：通过采样确认数据库最大 ID (MAX(id)) 和 WAL 文件大小不再增长，以验证防护成功。

4. GPT 用户的注意事项： 作者特别指出，对于使用 GPT 相关工具的用户，通过提示词生成的防护代码可能在后续下载新的 npm 包时被覆盖或失效。因此，用户需要严格区分“升级新版本”和“重新应用提示词修复”的顺序，确保防护机制在每次更新后都能正确生效。

关键要点

• 硬件风险：Codex 的 Bug 会导致磁盘高频写入，直接威胁 SSD 等存储设备的物理寿命，需引起高度重视。
• 自动修复局限：虽然 CLI v142 声称已修复，但 AI 自身对修复逻辑的解释并不透明或可靠，用户不应完全依赖 AI 的自我诊断。
• 有效防护策略：
  • 使用 SQLite Trigger 拦截 logs 表的写入是较为底层且有效的技术手段。
  • 必须包含备份、WAL 清理和效果验证三个步骤，形成闭环。
  • 推荐的提示词逻辑：检查日志文件 -> 备份 -> 拦截 Insert -> 清理 WAL -> 验证增长停止。
• GPT 用户特殊提醒：GPT 生成的防护代码易被 npm 包更新覆盖，用户需手动维护防护脚本，并注意操作顺序。
• 替代方案考量：鉴于 AI 工具潜在的不稳定性，作者建议用户在遇到严重 Bug 时，考虑评估 Claude Code (CC) 或 OpenCode 等替代产品。

意义与影响

这一事件揭示了当前 AI 编程助手在工程稳定性方面的一个盲点：AI 生成的代码或行为可能产生意想不到的副作用，甚至对运行环境造成物理损害。

1. 对开发者的警示：开发者在使用 AI 辅助编程时，不能盲目信任其输出。对于涉及系统底层、文件 I/O 或资源管理的操作，必须保持警惕，并建立相应的监控和防护机制。
2. 提示词工程的价值：在 AI 出现 Bug 时，通过精心设计的提示词引导 AI 生成修复代码或防御性代码，是一种快速响应的有效手段。但用户需要具备验证这些代码有效性的能力。
3. 工具选择的理性回归：该 Bug 暴露了单一工具依赖的风险。当核心工具出现严重缺陷时，拥有备选方案（如 CC、OpenCode）并能快速切换，是保障工作效率和数据安全的关键。
4. 社区协作的重要性：此类问题的发现和解决方案的传播，依赖于社区（如 LINUX DO）的共享。用户通过分享具体的提示词和技术细节，帮助他人规避风险，体现了开源和协作精神在解决 AI 时代新问题中的重要作用。