Codex Was Torching Your SSD and Nobody Noticed for Months

7.7 relevance

Important discovery about Codex SSD wear, highly actionable for anyone using Codex in production.

General dev.to

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

For platform engineers and developers running local AI tools or CLI agents, this highlights how bounded SQLite databases with WAL mode can silently destroy SSD lifespan through write amplification, a pattern that standard storage monitoring completely misses.

Key Takeaways

Audit your local developer tools for SQLite WAL write patterns using iostat or smartctl, not file size, and pin RUST_LOG to INFO or WARN to prevent TRACE-level logging from burning through SSD endurance.

Codex Was Torching Your SSD and Nobody Noticed for Months

Summary

Codex CLI's logs_2.sqlite SQLite database, despite remaining small in file size, caused ~37 TB of SSD writes over 21 days on one developer's machine due to a default TRACE logging level that generated constant insert-and-delete cycles. The WAL file amplified write amplification, and standard disk usage checks (du, ls) showed nothing abnormal because the database retained a bounded row count. Version 0.142.0 reportedly reduced log writes by ~85% by fixing the RUST_LOG override that failed to suppress verbose TRACE entries from WebSocket, OpenTelemetry, and dependency bridge paths.

Author

Varshith V Hegde