OpenAI Codex bug floods SSDs with logs — up to 640 TB/year, eating drive endurance

A GitHub issue against OpenAI’s Codex CLI documents a logging defect that writes staggering volumes of data to local disks. The reporter measured roughly 37 TB written over 21 days of uptime, with Codex’s SQLite feedback database (~/.codex/logs_2.sqlite and its WAL/SHM files) identified as the dominant continuous writer. Extrapolated, that’s about 640 TB per year — enough to exhaust the rated write endurance of a typical 600 TBW consumer SSD in under twelve months.

The root cause is write amplification driven by an over-broad logging configuration: the SQLite sink is installed with a global TRACE default (Targets::new().with_default(Level::TRACE)), so everything gets persisted. The database retains only ~0.5M rows even though its AUTOINCREMENT counter has passed 5.5 billion IDs — a ~10,000x gap revealing a relentless insert-index-prune churn cycle (about 36,000 rows inserted in a 15-second sample while retained count stayed flat). The noise is dominated by low-value dependency chatter: inotify open events for files like ld.so.cache, tokio-tungstenite websocket internals, and mirrored OpenTelemetry telemetry. TRACE-level entries account for ~71% of retained bytes, with codex_otel mirror events adding another ~25%.

The proposed fix keeps feedback logging but narrows defaults: drop the global TRACE level, suppress dependency and OTEL SDK noise, store payload summaries (event kind, duration, byte length) instead of raw websocket/SSE bodies that may contain private conversation content, and enforce a global DB size/write cap rather than relying on per-thread limits. The issue links to roughly a dozen related reports of unbounded log growth, idle-process disk thrashing, and WSL2 I/O saturation, suggesting a systemic logging problem rather than an isolated edge case.