OpenAI代码助手Codex存在严重日志写入漏洞，在21天内向本地SSD写入了约37TB数据，年化约640TB，可能在不到一年内耗尽消费级SSD的写入寿命。
问题根源
Codex的SQLite反馈日志模块（~/.codex/logs_2.sqlite）在安装时采用了全局TRACE级别配置，默认将所有日志目标（包括依赖库内部事件）持久化。用户实测发现，最高频的日志源是系统级的inotify文件监控事件（如读写ld.so.cache、locale.alias、passwd等系统文件），单个事件类型单日重复超过12万次。TRACE级别日志占保留字节的70.7%，叠加codex_otel.log_only和trace_safe遥测镜像又占25.3%，过滤这四类可削减约96%的日志量。
更严重的是写入放大：15秒采样内插入36211行，保留行数却基本不变——数据先插入、建立索引、写入选课日志（WAL），随即被裁剪，整个过程反复循环，造成远超实际需要的写入量。
对SSD的影响
消费级1TB TLC SSD通常标注600TBW（总写入量质保），按Codex当前速率，每年写入量相当于这块盘全部写入寿命。在WAL模式加持下，即使删除日志文件，被挂起进程占用的WAL仍会持续占用磁盘空间。
修复方向
Issue建议不要为SQLite日志sink启用全局TRACE级别，对低价值噪音（tokio-tungstenite内部事件、inotify系统调用、OpenTelemetry SDK日志）提高阈值或直接丢弃；不持久化完整原始websocket/SSE负载，改为存储事件类型、时长、成败状态和字节长度等摘要；增加全局日志数据库写入上限。
编注：材料为GitHub Issue #28224，用户实测数据，Codex官方尚未正式回应。