– Continuous SQLite logging in Codex CLI can cause ~640 TB of writes per year, exceeding most consumer SSDs’ lifetime endurance (≈600 TBW).
– The default global TRACE-level logging logs excessive noise (e.g., WebSocket payloads, filesystem events) and ignores the RUST_LOG environment variable.
– Write amplification from tens of thousands of insert/delete cycles per minute makes the physical drive damage worse than file size suggests.
– The bug has been known since at least April but remains unpatched despite recent unrelated SQLite fixes.
– Temporary workaround: symlink `~/.codex/logs_2.sqlite` to `/tmp/` to redirect writes to RAM (safe to lose on reboot).
Heavy SSD Wear From Codex CLI Bug
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.
Insane Write Volumes
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 Real Culprit: Misconfigured Logging
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.
Mostly Useless Noise
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.
History of Neglect
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.
Workaround for Linux and macOS
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.