OpenAI Codex的SQLite反馈日志每年可写入约640TB数据，导致固态硬盘寿命快速耗尽。

好的，作为一名专业的中文编辑，我已将您提供的英文内容（GitHub Issue #28224）的核心信息提炼并重述如下，同时删除了与主题无关的导航、用户界面元素和重复的讨论内容。

核心问题：Codex SQLite 反馈日志导致 SSD 写入量巨大，严重消耗硬盘寿命

问题描述：

OpenAI Codex 工具在运行时，会持续向本地的 SQLite 数据库（~/.codex/logs_2.sqlite 及相关文件）写入大量反馈日志。经用户实测，在约21天的运行时间内，SSD 产生了约 37 TB 的写入量。按此推算，年写入量可达 640 TB。对于一个 1TB 且写入寿命为 600 TBW 的消费级 SSD 来说，这意味着不到一年就会耗尽硬盘的保修写入寿命。

问题根源：

Codex 的 SQLite 日志记录器默认开启了全局的 TRACE 级别日志记录。这导致大量低价值、高频率的内部依赖库日志（如 tokio-tungstenite 的 WebSocket 内部细节、inotify 文件监控事件等）以及重复的遥测镜像日志（codex_otel.log_only 和 codex_otel.trace_safe）被持久化到数据库中。

关键证据：

1. 写入放大：数据库的保留行数看似稳定，但实际写入量巨大。在15秒的采样中，虽然保留行数未变，但插入了约 36,211 行新数据，同时删除了等量的旧数据，形成了持续的“插入-修剪”循环，造成严重的写入放大。
2. 日志内容分析：在保留的日志中，TRACE 级别日志占比高达 70.7%，而 codex_otel 相关的 INFO 日志又占了 25.3%。这两类日志合计占据了约 96% 的存储空间，但价值极低。其中包含了大量如 inotify 事件、WebSocket 连接状态等噪音信息。

提出的解决方案：

用户建议在不完全禁用反馈日志的前提下，通过以下方式优化默认配置：

1. 取消全局 TRACE 级别：不要将 SQLite 反馈日志的默认级别设为 TRACE。
2. 提高低价值日志的阈值：对 log、hyper_util、tokio-tungstenite 等内部依赖库的日志，以及 codex_otel 的镜像日志，提高其记录级别（如设为 WARN 或更高），以减少写入。
3. 避免存储原始负载：不要持久化完整的 WebSocket/SSE 原始数据，改为存储摘要信息（如事件类型、耗时、成功/失败状态等）。
4. 增加全局写入上限：为整个日志数据库设置大小或写入量的硬性上限。
5. 提供配置开关：提供一个如 sqlite_logs_enabled = false 的选项，让用户能彻底关闭此功能。

社区反应与临时方案：

该问题被标记为“严重错误”，因为其不仅消耗硬件寿命，还可能导致磁盘空间被写满，进而引发系统登录失败或 Codex 在“目标”模式下误删文件等数据丢失风险。

在官方修复前，社区用户提供了几种临时缓解方案：

• 使用 SQLite 触发器：在数据库中创建一个 BEFORE INSERT 触发器，在写入前直接丢弃高频率、低价值的日志行。此方法能显著降低写入量，但无法阻止 Codex 在应用层格式化日志事件。
• 编写脚本清理：提供脚本定期对 WAL 文件执行检查点操作以缩小其体积，或在紧急情况下杀死所有 Codex 进程并删除日志文件以立即释放磁盘空间。
• 使用第三方工具：有用户制作了社区工具（如 codex-fixes），可一键应用社区发现的各类临时修复方案。

根据评论内容，总结如下：

主要观点与论据：

1. Codex存在严重Bug，导致资源耗尽：评论指出Codex在空闲时持续写入大量日志，导致SQLite数据库膨胀至27GB，并造成GPU 100%占用、风扇狂转等问题。该Bug已存在近6个月，OpenAI未修复。

   • "THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!!" (b--l)
   • "SQLite + unbounded TRACE logs = firehose in a bathtub. No rotation, no cap, no surprise." (abihordun)

2. 对“Vibe Coding”质量的质疑：评论认为此类Bug源于AI生成的代码缺乏深度理解，导致“理解债务”（comprehension debt），即使测试通过也难以维护。

   • "The first of many bugs that are beyond the complexity of its authors, thanks to comprehension debt." (rvz)
   • "Vibe coding takes 'move fast and break things' to a whole nother level." (neuralkoi)

3. OpenAI的沉默与应对不力：评论批评OpenAI对严重Bug保持沉默，未及时回应或修复，损害了用户信任。

   • "OpenAI's silence is worse than the bug." (abihordun)
   • "Been open a week and AFAICT just silence from OpenAI." (i2km)

4. 与竞品对比：部分评论认为Claude Code在质量和响应速度上优于Codex，后者存在明显倒退。

   • "I want to like codex, but the quality is just not very good, especially when compared to Claude." (purpleidea)
   • "OpenAI really snatched defeat from the jaws of victory late last year when Claude Code was a laggy mess." (taspeotis)

5. 对AI开发模式的反思：评论指出AI公司应重视测试和问题跟踪，避免盲目加速开发，否则可能加速自身失败。

   • "AI has both uphills and downward valleys and cliffs. It might as well just accelerate you, which could be, towards your downfall as well." (Imustaskforhelp)
   • "The only logical conclusion... is: An (vibe-coded?) product is hard to maintain even for some of the best engineers." (Imustaskforhelp)

平衡性说明：评论整体对Codex持批评态度，但部分评论也承认类似Bug在传统开发中可能出现，并反思AI能否超越人类智能的局限。