Codex 日志漏洞修复：0.142.0 降噪但未根治

AI工具安装API平台故障排查模型订阅与入口

2026-06-23 12:47

412 浏览

0 点赞

AI 速览

OpenAI发布Codex 0.142.0版本修复日志过度写入漏洞，适合使用Codex的开发者规避硬件损耗。核心事实 - 问题背景：Codex默认TRACE日志等级导致SQLite高频写入，年化达640TB，耗尽SSD寿命 - 修复措施：0.142.0版本合并PR #29432和#29457，停止记录完整WebSocket payload及过滤低价值日志 - 实际效果：仅实现“降噪”，未根治问题，WAL文件仍在增长，Issue #28224保持开放状态 - 临时方案：建议用户执行WAL checkpoint截断、清理旧文件或配置符号链接至/tmp 价值点帮助开发者识别并缓解AI编程工具的本地存储风险，提供具体的运维排查与应急处理手段。

6月23日消息，OpenAI 发布 Codex 0.142.0（rust-v0.142.0），针对近期引发广泛关注的 SQLite 日志系统过度写入问题推出首次官方缓解措施。该版本通过合并两个降噪补丁，减少 WebSocket 全量 payload 日志和部分 OTel 镜像事件的写入，但问题尚未彻底解决——默认日志等级仍为 TRACE，高频底层事件仍在持续写入。

问题根源：默认 TRACE 等级致 SSD 年写入量达 640TB

Codex SQLite 日志接收器（由早期 PR #12969 引入）默认使用全局 TRACE 等级。在长时间运行或 Agent 工作流中，这一配置导致极高频率的插入操作：每次成功 WebSocket 响应、OpenTelemetry 事件和 log crate 的 debug 信息都被完整记录。

持久化路径为 ~/.codex/logs_2.sqlite + WAL（Write-Ahead Log）文件 + shm 文件，采用 WAL 模式运行。高频的"插入→清理→再插入"循环产生了严重的写入放大效应。

实际影响：GitHub Issue #28224 记录了 21 天内写入约 37TB 的实测数据，年化约 640TB。一块典型的 1TB 消费级 SSD 总写入寿命（TBW）约为 600TB——重度 Codex 用户可能在数月内耗尽 SSD 全部寿命。该 Issue 创建于 6 月 14 日，至今仍为 Open 状态，社区讨论活跃。

部分用户还反馈，磁盘写满后 Codex 在 /goal 模式下可能出现激进的清理行为，存在误删用户文件的隐患。

0.142.0 修复内容：降噪而非根治

6 月 22 日发布的 0.142.0 版本合并了两个关键 PR，均由贡献者 jif-oai 提交：

PR #29432：停止记录每次成功的 Responses WebSocket 事件的完整 payload（TRACE 级别），同时停止发射对应的 OpenTelemetry log/trace 事件。保留了计数器和时长指标等聚合数据。

PR #29457：在持久化 SQLite sink 中过滤以下高频低价值目标日志：target=log（bridged 事件）、codex_otel.log_only、codex_otel.trace_safe。

官方发布说明中 Chores 部分的描述为："Reduced persistent-log churn by removing per-event WebSocket payload logging and filtering duplicated telemetry records (PRs #29432, #29457)。"

这是一个偏向"降噪"而非"彻底关闭"的修复方案——SQLite sink 层面的默认日志等级仍然为 TRACE，只是在产生层对部分高频目标进行了过滤。

社区反馈：明显改善但未停止

升级后的 macOS 和 Windows 用户反馈基本一致：logs_2.sqlite + WAL 文件的增长速度明显放缓，但尚未停止。

典型反馈包括：

srid（macOS）：升级后 60 秒内 max_id 仍在增加，target=log 仍占主导

0xdevalias：问题"有所缓解但未完全修复"

pwukun（Windows）：文件已达 6.5GB + 101MB WAL

相关新议题包括 #28997（WAL 无限制增长）和 #29532（0.142.0 后仍存在 TRACE target=log 日志流失）。

当前推荐方案

在更彻底的修复（如将 SQLite sink 默认降至 INFO/WARN，或提供配置开关）到来之前，社区建议：

升级至 0.142.0 作为基础防护

定期执行 WAL 检查点截断：sqlite3 ~/.codex/logs_2.sqlite "PRAGMA wal_checkpoint(TRUNCATE);"

清理脚本：停止 Codex 后删除 logs_2.sqlite* 文件（会重新生成，但可释放已占空间）

SQLite TRIGGER 临时方案：阻止 TRACE 级别插入（保留对话历史）

临时解决方案（不写入 SSD）：

ln -sfn /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite
# 重启 Codex 后生效

总结

0.142.0 是 OpenAI 对 Codex 日志问题首次官方响应，效果定位为"降噪"而非"根治"。Issue #28224 仍为 Open 状态，部分用户升级后仍有持续写入。建议用户升级至最新版并配合 WAL checkpoint 脚本使用，同时持续关注 GitHub 上的后续修复动态。

好文章，需要你的鼓励

# 报错信息分析与调试指南 ## 任务说明请分析用户提供的报错信息，推测可能的错误原因，并提供系统性的调试步骤。 ## 分析要求 1. **错误类型识别** - 确定是语法错误、运行时错误、逻辑错误还是环境配置错误 - 识别具体的错误类别（如空指针、数组越界、类型不匹配等） 2. **原因推测** - 基于错误信息中的关键线索进行合理推断 - 考虑常见的导致此类错误的编程场景 - 分析可能的代码问题或环境问题 3. **调试步骤** - 提供从简单到复杂的逐步调试方法 - 包括代码检查、日志添加、环境验证等具体操作 - 给出预防类似错误的最佳实践建议 ## 输出格式 - **错误类型**：[具体的错误分类] - **可能原因**： 1. [原因1] 2. [原因2] 3. [原因3] - **调试步骤**： 1. [步骤1] 2. [步骤2] 3. [步骤3] 4. [步骤4] - **解决方案**：[具体的修复建议] ## 示例 **输入**：【报错信息】 ``` TypeError: Cannot read property 'length' of undefined at processData (app.js:25:18) at main (app.js:10:5) ``` **输出**： - **错误类型**：运行时错误 - TypeError - **可能原因**： 1. 变量未正确初始化就被访问其 length 属性 2. 函数参数传递了 undefined 值 3. 异步操作中数据还未加载完成就尝试访问 - **调试步骤**： 1. 检查 app.js 第25行附近的变量声明和赋值 2. 在访问 length 属性前添加类型检查：`if (variable && variable.length)` 3. 使用 console.log() 输出相关变量的值确认其状态 4. 检查函数调用时传入的参数是否正确 - **解决方案**：在访问对象属性前先验证对象是否存在，或确保变量在使用前已被正确初始化。