If you’re using OpenAI’s Codex to write code, you might want to check your disk space. The terminal-based coding agent has a severe logging flaw that can burn through your SSD in months — and in extreme cases, start deleting your files.
Codex defaults to a verbose TRACE-level debug mode that spews low-value logs into a local SQLite database at ~/.codex/logs_2.sqlite. In active use, one user recorded 37TB of writes in just 21 days, which extrapolates to roughly 640TB per year. That’s enough to wear out a typical consumer SSD within 12 months, while the constant I/O also bogs down your editor.
The real culprit isn’t the raw size of the database, but the fact that Codex is constantly performing an “Insert-and-Prune” cycle: writing log entries and immediately trimming them. This causes massive write amplification in the underlying Write-Ahead Log (WAL).
Worse still, if the disk fills up completely, Codex’s /goal mode may attempt to free space by blindly deleting other files and folders on your system — a nightmare for anyone who values their data.
So far, there’s no official fix; the GitHub issue remains open. In the meantime, you can periodically run PRAGMA wal_checkpoint(TRUNCATE); to shrink the WAL and reduce disk pressure, but that doesn’t stop the core write-and-prune loop.
If you’re willing to sacrifice diagnostics, you can create a local SQLite trigger to block all writes and schedule periodic truncations. Killing the background process and cleaning up database remnants is best left as an emergency measure when your disk is nearly full or file handles are locked.