OpenAI Codex 的本地 SQLite feedback log 系统被曝出现异常写入：21 天累计写入 37 TB，按年化计算约为 640 TB。这一数字已经高于多数消费级 SSD 常见的 300 至 600 TBW 额定写入寿命，意味着若持续运行，硬盘寿命可能被明显压缩。
问题由 GitHub 用户 @1996fanrui 于本月中披露。其在日常使用 Codex 时发现本机磁盘空间消耗异常，追查后定位到一个本地 SQLite 数据库。该数据库当前占用约 1.2 GiB，保留约 506,149 行记录，但历史 row ID 已达到 55 亿，显示系统虽在清理旧记录，写入速度却远高于清理速度。
TRACE 日志和遥测副本构成主要写入来源
从日志结构看，问题集中在高频、细粒度记录。素材显示，TRACE 等级日志占 70.7%，OpenTelemetry 遥测映像占 25.3%，其余部分占 3.9%。TRACE 属于最细的日志级别，通常不应在正式产品环境中持续写入本地磁盘。
技术上，异常写入主要来自四个方向：WebSocket 事件日志、inotify 文件系统通知、依赖包内部日志，以及 OpenTelemetry 遥测映像。素材提到，Codex 会把底层 WebSocket 事件写入 SQLite���同时，工作目录变化触发的 inotify 事件也会持续入库。第三方依赖在初始化和运行中的 TRACE 日志也被一并持久化。另一个关键点是，原本准备用于上传远端端点的遥测数据，也被完整复制到本地 SQLite 中。
两项修复已合并，仍有约 15% 写入未消除
针对这一问题，修复方案由两个 PR 组成：PR #29432 停止记录每个 WebSocket 事件，PR #29457 过滤高频 target。官方表示，这两项修复合计可消除约 85% 的问题写入量。
不过，剩余部分并未完全消失。按素材中的年化口径估算，未解决的 15% 仍相当于每年约 96 TB 的写入量。这一水平虽然低于初始状态，但对消费级 SSD 仍不是小数目。
本地行为缺乏提示引发透明度讨论
素材指出，这次问题最受关注的不只是日志等级配置失当，还在于用户并未被主动告知。披露者是在察觉磁盘异常后才开始排查，而不是收到 Codex 的明确提醒。若用户没有监控磁盘写入的���惯，这类行为可能持续存在，直到硬盘寿命被消耗或存储空间接近耗尽。
文章还提到，本地保留 OpenTelemetry 遥测副本一事，与隐私和合规讨论存在交集。尤其是在金融、医疗、法律等受管制行业，或高机密环境中，本地留存此类副本本身就需要被审视。素材显示，从问题发现到 issue 关闭共经历 8 天，响应不算慢，但剩余写入和告知机制仍留下争议。