Codex 爆史诗级bug：你的硬盘在急速消耗

最近发现Codex存在一个比较严重的日志写入问题，建议正在使用或计划高强度使用的朋友尽快关注。 Codex在处理长时间流式任务或Agent模式时，会以极高频率向 ~/.codex/logs_2.sqlite 文件写入TRACE级别日志。这种高强度写盘行为会快速消耗SSD的TBW（总写入量）。 有用户反馈，持续高负载下21天左右即可产生约37TB写入，一年可能超过600TB（通常总共也就这么多）。 对消费级SSD来说，这属于严重损耗，容易导致硬盘提前老化、性能下降甚至提前损坏，同时伴随系统卡顿和发热增加。 快速自查方法： 在Codex中直接输入：“帮我检测 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘？”即可确认。 止损处理步骤（备份后再操作）： 1. 先备份日志文件； 2. 使用SQLite trigger拦截logs表写入； 3. 执行checkpoint并truncate WAL； 4. 确认MAX(id)不再增长且WAL文件稳定。 操作完成后，建议将日志目录迁移到单独分区、机械硬盘或内存盘（tmpfs），或临时限制Codex长时间连续运行。 日常防护建议： • 非必要时避免长时间挂起流式任务，完成后及时关闭； • 重要项目优先放在云端，减少本地高强度使用； • 使用iotop、smartctl或CrystalDiskInfo等工具定期监控磁盘写入量； • 关注官方更新，补丁发布后及时升级。 这个问题本质是TRACE日志默认开启过于激进，适合调试但不适合生产级长时间运行。目前社区已有反馈，官方正在跟进修复。 本地AI工具虽强大，但这类基础设施问题若不注意，硬件成本会显著增加。保护好SSD，就是保护自己的时间和预算。建议大家在使用任何本地AI工具时，都养成关注资源占用的习惯。 有同样经历的朋友欢迎评论区交流实际写入数据和处理效果，一起避坑。 我是 Levi，每日手动筛选高价值AI 资讯，如果你也对AI感兴趣想定时获取有效信息就关注我吧！ #codex #每日资讯#howto用好AI