OPENAI
Small, quiet and silently destructive
OpenAI’s Codex CLI may be putting huge strain on some users’ SSDs because of a logging bug that is still open on GitHub.
The issue was flagged by GitHub user 1996fanrui on June 14, after they noticed unusually high disk activity.
They found that Codex was constantly writing diagnostic logs to a local SQLite database stored at ~/.codex/logs_2.sqlite.
Over 21 days, their drive recorded around 37TB of writes. If that continued for a full year, it would add up to about 640TB.
For context, some 1TB consumer SSDs are rated for around 600TBW across their lifetime, meaning this bug could burn through a drive’s warranted endurance in under a year.
Very normal behaviour from a log file... that is apparently auditioning for a demolition job.
The problem seems to come from a logging setting that was likely never meant for regular users.
Codex’s SQLite feedback sink runs at global TRACE level by default, which is the most detailed logging mode.
That means it records a huge amount of low-level activity, including WebSocket payloads and routine file system events. What makes it worse is there’s no way to reduce the level of logging - it’s hardcoded to always do the absolute maximum.
The database file may not look huge, but the constant insert-and-delete activity can still cause far more physical writes than the file size suggests.
The main points:
Codex CLI is reportedly writing large amounts of diagnostic data to a local SQLite file.
One user recorded around 37TB of writes in 21 days, which could reach around 640TB in a year.
The issue has been raised on GitHub and remains open.
Logs gone ferocious
For now, Linux and macOS users can redirect ~/.codex/logs_2.sqlite to /tmp/ using a symlink, which moves the writes to temporary storage.
The file does not contain conversation data, so losing it after a reboot should be fine.
Tiny silver lining: your SSD is not dying in battle. It is being slowly defeated by admin.
Codex logs every time you blink. - MV