A serious storage problem has been found in OpenAI’s Codex CLI. Left running, the tool can wear out a solid-state drive in less time than most warranties even cover. The cause isn’t exotic. It’s a logging setting that was never dialed back before release.
In This Blog Post
- How Is Codex SSD Bug Quietly Killing Your Drive?
- What Causes the Codex Bug?
- What Makes the Codex SSD Bug Issue Worse?
- How Can You Fix the OpenAI Codex Bug?
- Wrap Up
- FAQs
How is Codex SSD Bug Quietly Killing Your Drive?
The issue was flagged on GitHub on June 14 by a user going by 1996fanrui. Unusually high disk activity had been noticed on their machine. The source was traced back to Codex. A local SQLite database, stored at “~/.codex/logs_2.sqlite”, was being written to constantly. Diagnostic logs were pouring into it nonstop.
| The numbers are what make this alarming. Over 21 days of uptime, around 37 TB had been written to the drive. Annualized, that works out to roughly 640 terabytes a year. |
For comparison, a 1 TB consumer SSD is rated for about 600 TBW over its whole lifetime. That number is meant to be spread across many years of normal use. Instead, it could be used up by a single buggy tool in under 12 months. That’s only if nothing else is being written to the disk at the same time.
SSDs don’t fail the way hard drives do. Flash memory cells can only be written and erased a finite number of times before they wear out and start losing the ability to hold data reliably. Manufacturers publish a TBW rating precisely so buyers know how much writing a drive can absorb before that wear becomes a real concern. A bug that pushes a drive past that number in a fraction of the expected timeframe isn’t a performance annoyance. It’s a hardware lifespan issue.
What Causes the Codex Bug?
The root cause is a logging level that was set far too aggressively. Codex’s SQLite feedback sink runs at TRACE by default, which is the most verbose logging mode available.
At that level, practically everything gets recorded:
- Raw WebSocket payloads
- Routine filesystem events
- The tool opening system files (like “passwd” or “ld.so.cache”)
None of that is meant to be useful to an end user. Around 71% of what’s being logged is TRACE-level noise. It has no real diagnostic value for anyone outside of OpenAI’s own engineers. Such details belong in an internal debugging build, not in software running unattended on someone’s laptop.
Normally, such an issue is an easy fix. Most command-line tools built in Rust respect the RUST_LOG environment variable. This lets users dial logging verbosity up or down. However, Codex ignores it. There’s no built-in way to turn the noise off. It means the excessive writes just keep accumulating in the background with no obvious off-switch.
What Makes the Codex SSD Bug Issue Worse?
The raw log volume alone would be bad enough, but the way the database handles it makes the real-world damage even bigger. The SQLite file isn’t simply growing in a straight line. It’s cycling through tens of thousands of insert-and-delete operations every minute.
That constant churn causes something called write amplification. The actual data physically written to the flash memory ends up being much larger than the logical size of the file would suggest. So the file size shown on disk understates just how much wear is being inflicted on the underlying hardware. The drive is absorbing far more punishment than a casual glance at the log file would ever reveal.
Is the OpenAI Codex SSD Bug a New Problem?
This isn’t the first time something like this has surfaced. Related reports have been filed going back to at least April, describing similar excessive-write behavior in various forms. OpenAI’s changelog has touched on SQLite reliability at points since then, but those fixes addressed stability, not the underlying write rate. As of now, the GitHub issue documenting the 640 TB/year figure remains open, with no official fix shipped.
For a coding assistant marketed as something developers should be comfortable leaving running for long sessions, that’s a notable gap. Anyone using Codex CLI regularly, especially on a laptop with a single, non-replaceable SSD, is effectively running a background process that’s slowly working against their own hardware.
How Can You Fix the OpenAI Codex Bug?
Until OpenAI patches this properly, there is a workaround for Linux and macOS users. The fix involves symlinking the log file to a location in memory instead of on disk:
~/.codex/logs_2.sqlite → /tmp/Redirecting the file to /tmp/ sends the writes to RAM rather than to the SSD. The file only holds diagnostic and feedback data, not actual conversation history. It means losing it on reboot doesn’t cost anything meaningful. It’s a workaround, not a real solution. Still, it’s enough to stop the drive from taking ongoing damage.
Windows users don’t currently have an equivalent fix available, since the symlink trick relies on how /tmp/ is typically handled as a RAM-backed or frequently-cleared location on Unix-like systems.
Wrap Up
Bugs that quietly chip away at hardware lifespan don’t cause an obvious crash or error message. Everything appears to work fine on the surface, right up until a drive starts throwing errors or dies outright. This particular case is a reminder that AI coding tools are still software with the same categories of bugs as anything else, including the kind that can cost users actual money in hardware.
FAQs
The bug affects any system running Codex CLI. The available workaround is specific to Linux and macOS.
Not fully. OpenAI’s changelog has addressed some SQLite reliability issues since April. The underlying write-rate problem hasn’t been resolved. The GitHub issue remains open.
Around 37 TB was written over 21 days of uptime in the case that surfaced the issue. It works out to about 640 TB a year. Frequent insert-and-delete cycles in the database also cause write amplification. The real wear on the drive is higher than the log file’s size alone would suggest.
