OpenAI Codex Bug Was Silently Burning Through SSD Endurance at 640 TB a Year
- Linux Kernel Removes strncpy After Six Years and 362 Patches
- Linux Kernel Drops 40-Year-Old AppleTalk Protocol — AI-Generated Patch Flood Was the Last Straw
- Apple’s Native Linux Container Tool Has Arrived — But Can It Really Replace Docker?
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
OpenAI Codex Bug Was Silently Burning Through SSD Endurance at 640 TB a Year
A runaway SQLite logging configuration inside the popular coding agent was generating more write traffic than most consumer drives are warranted to handle in their entire lifetime — fixes have now been merged.
A bug in OpenAI’s Codex coding agent has been writing staggering amounts of data to developers’ local solid-state drives — silently, continuously, and at a rate that exceeds the rated lifetime endurance of many consumer drives in under twelve months. The issue was documented on GitHub on June 14 by developer Rui Fan, who noticed unusually high disk activity and traced it to a local SQLite database Codex maintains at ~/.codex/logs_2.sqlite.
After 21 days of normal operation, Fan’s main SSD had absorbed roughly 37 TB of writes attributable to Codex alone. Annualised, that extrapolates to approximately 640 TB per year. For context, many 1 TB consumer NVMe drives carry a total write endurance rating of around 600 TBW across their entire service life — meaning a single year of running Codex could exhaust that warranty budget entirely.
The Root Cause: Maximum-Verbosity Logging Shipped to Production
The culprit is Codex’s SQLite feedback sink, which ships configured at global TRACE level — the noisiest setting available. It records everything from raw WebSocket payloads and filesystem metadata lookups to routine OpenTelemetry diagnostic events. Approximately 71% of what is logged has no practical diagnostic value for the average user. Worse, the logger ignores the standard RUST_LOG environment variable, meaning there was no obvious way for users to quieten it through normal means.
A further complication is write amplification. The database does not grow visibly — it prunes rows about as fast as it inserts them, keeping the file size deceptively calm. In one 15-second window, over 36,000 rows were inserted while the total retained row count held flat at around 680,000. But SQLite’s WAL (write-ahead log) mode means the drive controller absorbs far more physical writes than the logical database size implies. The SQLite auto-increment counter had surpassed 5.5 billion, betraying a history of enormous write throughput that the file’s tidy on-disk size completely concealed.
Why It Went Unnoticed for So Long
The damage was almost invisible to standard tooling. Checking available disk space showed nothing unusual; the database file appeared small. Only by reading the drive’s own SMART health counters could users see the true write load accumulating. The underlying problem actually appeared as early as April 2026, when a separate GitHub issue documented write rates of around 5 MB/s during streaming sessions, with peaks reaching 16 MB/s. At least eight distinct issues across the Codex repository describe different symptoms of the same root behaviour, but none attracted the wider attention that followed when Fan attached a concrete annual TBW figure and Hacker News picked up the thread in June.
The situation is especially consequential for developers on modern laptops, where NVMe storage is frequently soldered to the motherboard. Endurance loss there is permanent — and when a soldered drive wears out, the remedy is often a new machine rather than a drive swap.
There Were Also Reports of Boot Failures
Beyond hardware wear, some users encountered a more immediate problem: the Codex desktop application becoming unable to start at all due to log bloat. Excessive growth in the database and its associated WAL files caused startup failures, adding a reliability concern on top of the long-term endurance risk.
As a temporary workaround for users not yet on a patched version, Linux and macOS users can redirect ~/.codex/logs_2.sqlite to /tmp/, causing writes to land in RAM rather than on the SSD. Since the log file contains no conversation or project data, losing it on reboot carries no meaningful cost. Windows users did not have an equivalent workaround and were advised to update as soon as a patched build became available.
A Broader Lesson for Agentic Developer Tools
Shipping trace-level logging into production is a classic software mistake that long predates AI coding assistants. What sets this case apart is scale: modern SSDs are fast enough that an application can sustain enormous write throughput while remaining perfectly usable, making the damage easy to miss until significant wear has already accumulated. As coding agents become persistent background processes — watching filesystems, streaming data, and maintaining local context — their operational footprint on consumer hardware demands the same discipline typically reserved for server-side services. The Codex incident offers a concrete, measurable illustration of what happens when it does not.
