Codex CLI logging bug may heavily wear down SSDs
OpenAI’s has a reported logging problem that can create very large SSD writes when it is left running for long periods. The tool keeps writing diagnostic logs into a local SQLite file at `~/.codex/logs_2.sqlite`. A June 14 measured about 37 TB of writes over 21 days, which works out to roughly 640 TB in a year.
A typical 1 TB consumer SSD is often rated for about 600 TBW, so this level of writing could use up the drive’s warranted write life in under a year. The likely cause is a logging setup that runs at the very noisy TRACE level by default and records things like data and ordinary events. The usual RUST_LOG setting does not appear to quiet it easily, and about 71% of the logged data was described as low-value TRACE noise.
The problem is worse than the visible file size suggests because the database is doing many insert and delete per minute, causing write amplification. A temporary Linux and macOS is to symlink `~/.codex/logs_2.sqlite` to `/tmp/`, which redirects the writes to RAM; the file reportedly does not store conversation data, so losing it after reboot is acceptable.
Key points
- may write excessive logs to `~/.codex/logs_2.sqlite`.
- One reported measurement found about 37 TB written in 21 days, or roughly 640 TB per year.
- That is close to the common 600 TBW lifetime rating for a 1 TB consumer SSD.
- TRACE-level logging and repeated SQLite insert/delete activity are the suspected causes.
- Linux and macOS users can temporarily symlink the SQLite file to `/tmp/` to reduce SSD writes.