OpenAI Codex has a bug that could kill your SSD in under a year

If you use OpenAI's Codex CLI and leave it running for long periods of time, your SSD may be getting hammered.

A GitHub user named 1996fanrui documented the issue on June 14 after noticing unusually high disk activity on their machine. After digging around, they found Codex was continuously hammering a local SQLite database (stored at ~/.codex/logs_2.sqlite) with diagnostic log writes. Over 21 days of uptime, the drive had absorbed around 37 TB of writes. Annualized, that's roughly 640 terabytes per year. A typical 1 TB consumer SSD is rated for about 600 TBW lifetime — so this bug, if left unchecked, could burn through your drive's entire warranted endurance in less than a year.

The culprit is a logging configuration that probably nobody meant to ship to end users. Codex's SQLite feedback sink runs at global TRACE level by default — the noisiest possible setting. It logs everything from raw WebSocket payloads to mundane filesystem events like opening 'passwd' and 'ld.so.cache'. It also ignores the standard RUST_LOG environment variable, so there's no obvious way to turn it down. Around 71% of the logged data is TRACE-level noise that has no real diagnostic purpose, for the average user at least.

What makes it worse is write amplification. The database isn't just growing, but also cycling through tens of thousands of insert-and-delete operations per minute. It is physically writing far more to the drive than the file size implies.

This has actually been a known issue in various forms since at least April, with multiple related reports filed across the year. OpenAI's recent changelog touched some SQLite reliability fixes but hasn't addressed the write rate problem. The issue is still wide open.

In the meantime, Linux and macOS users can symlink '~/.codex/logs_2.sqlite' to '/tmp/' to redirect writes to RAM. The file holds no conversation data, so losing it on reboot is fine.