OpenAI’s Codex, the terminal-based AI coding agent, has been hit with a serious logging defect. The issue comes from an internal component that enables excessive global TRACE-level debug output by default, causing Codex to furiously write low-value logs to a local database at ~/.codex/logs_2.sqlite.
Real-world testing shows that under heavy use, a device can write about 37 TB of log data in just 21 days — that’s roughly 640 TB per year. For a standard consumer SSD, that means the drive could be ground to a halt within a year. And the constant I/O doesn’t just wear out hardware; it also triggers sluggish editor performance.
What’s worse, the physical wear isn’t about the database growing large. The culprit is a repeating pattern of writing logs and immediately pruning them — a so-called insert-and-prune cycle — which creates severe write amplification in the underlying write-ahead log (WAL).
There’s also a more alarming consequence: if the disk fills up completely, Codex in /goal mode may start blindly deleting other files and folders in an attempt to free space. That’s a quick path to data loss.
As of now, the GitHub issue is still open with no official fix from OpenAI. For temporary relief, users can periodically run PRAGMA wal_checkpoint(TRUNCATE); to compress the WAL file and reduce log footprint — but that doesn’t stop the cycle at its source.
If you prioritize SSD lifespan, you can create a local SQLite trigger to block writes entirely, combined with periodic truncation. The trade-off is that diagnostic logs become completely unavailable. As for killing the background process and cleaning up database remnants, that’s best saved for emergencies when the drive is nearly full or handles are locked — it’s not a regular solution.