Codex日志BUG致Win11及Mac用户磁盘读写激增

背景

近期，在 LINUX DO 社区的 AI 板块中，关于 AI 编码助手 Codex 出现严重技术故障的讨论引发了广泛关注。该问题主要影响 Windows 11 结合 WSL2（Windows Subsystem for Linux 2）的用户群体，同时也波及 macOS 用户。据社区反馈，Codex 存在一个未被及时修复的 Bug，导致系统产生异常的高频磁盘读写操作。这一现象不仅造成了严重的性能损耗，更对固态硬盘（SSD）等存储介质的物理寿命构成了直接威胁。

核心内容

本次事件的核心在于 Codex 软件在运行过程中产生的日志记录机制存在缺陷。具体表现为：

1. 异常磁盘读写：Codex 在后台持续以 TRACE 级别记录日志，导致对本地数据库文件 ~.codex/logs_2.sqlite 进行高频写入。这种非正常的 I/O 负载对于依赖闪存介质的现代硬盘（尤其是 SSD）而言是致命的，因为 SSD 的写入寿命（TBW）是有限的，持续的高强度写入会加速存储颗粒的磨损。
2. 跨平台影响：虽然最初由 Win11 + WSL2 用户发现，但后续有 Mac 用户反馈也遭遇了类似情况，表明该问题可能并非局限于特定的操作系统环境，而是 Codex 软件本身的通用逻辑缺陷。
3. CPU 占用异常：除了磁盘问题，部分 Windows 用户还报告了 CPU 占用率飙升至 100% 的现象。用户指出，Codex 启动的相关服务进程会长时间占用极高的 CPU 资源，这可能是一个独立的 Bug，也可能与日志处理或后台服务死循环有关。
4. 社区排查方案：针对日志文件膨胀问题，社区提供了基于 SQLite 的技术排查与修复思路。建议用户首先备份数据库，然后通过 SQLite trigger（触发器）拦截对 logs 表的插入操作，进而执行 checkpoint 或 truncate WAL（Write-Ahead Logging，预写式日志）文件，最后通过采样确认数据库最大 ID（MAX id）和 WAL 文件大小不再增长，以验证修复效果。

关键要点

• 故障现象：Codex 导致 Win11+WSL2 及 Mac 用户出现大量磁盘读写，严重损耗硬盘寿命。
• 受影响文件：主要涉及 ~.codex/logs_2.sqlite 数据库及其关联的 WAL 文件。
• 潜在风险：
  • 存储设备物理寿命缩短（SSD 写入磨损）。
  • 系统性能下降（CPU 占用率长期 100%）。
• 技术排查建议：
  • 检查 ~.codex/logs_2.sqlite 是否存在 TRACE 日志高频写入。
  • 操作前务必备份数据。
  • 利用 SQLite trigger 拦截 logs 表 insert 操作。
  • 执行 checkpoint 或 truncate WAL 以释放空间。
  • 监控 MAX(id) 和 WAL 大小以确认问题是否解决。
• 社区热度：该话题在 LINUX DO 社区引发了热烈讨论，共有 81 个帖子和 61 位参与者参与互动。

意义与影响

此次事件暴露出 AI 辅助编程工具在稳定性、资源管理及日志策略上的不足。对于开发者而言，Codex 作为提升效率的工具，其自身却成为了系统资源的“黑洞”，这不仅违背了工具设计的初衷，更可能因硬件损坏带来不可逆的经济损失。

从行业角度看，这也提醒 AI 软件开发者，在追求功能迭代的同时，必须重视底层资源监控和日志轮转机制的健壮性。特别是对于涉及本地文件系统高频交互的应用，必须提供可配置的日志级别和自动清理机制，避免默认设置对普通用户的硬件造成隐性伤害。同时，这也反映了开源社区在发现并快速传播此类隐蔽 Bug 方面的积极作用，用户间的互助排查方案为官方修复提供了宝贵的技术参考。