OpenAI Codex CLI Bug May Wear Out SSDs With Excessive Logging

OpenAI’s Codex CLI is reportedly causing unusually high SSD write activity due to excessive diagnostic logging, raising concerns about potential long-term storage wear for users who leave the tool running continuously.

The issue was highlighted on June 14 by a GitHub user known as “1996fanrui,” who noticed abnormally high disk writes while using Codex CLI. Similar reports appear to have surfaced as early as April, suggesting the problem may have affected users for several months.

According to reports, the excessive writes originate from a local SQLite database located at ~/.codex/logs_2.sqlite. The database continuously records diagnostic information generated by the application.

Reports Point to Tens of Terabytes of SSD Writes

One user reported that Codex generated approximately 37TB of writes over a period of 21 days. If sustained for a full year, that rate would amount to roughly 640TB of writes annually.

For comparison, many consumer 1TB SSDs carry endurance ratings of around 600 terabytes written, or TBW, across their expected lifespan. While SSD endurance varies by model and manufacturer, sustained write activity at this level could significantly accelerate wear on affected drives.

The root cause appears to be Codex’s SQLite feedback sink operating at the global TRACE logging level by default. TRACE is the most verbose logging mode available and records large amounts of diagnostic information.

Reports indicate that the logs include raw WebSocket payloads, filesystem events, and other low-level telemetry that provides limited value for most users during normal operation.

Logging Controls Reportedly Do Not Work as Expected

Users have also reported that Codex’s logging system ignores the standard RUST_LOG environment variable, making it difficult to manually reduce logging verbosity.

Analysis shared in the GitHub discussion suggests that approximately 71% of the recorded data consists of TRACE-level logging noise. While useful for debugging specific issues, this level of detail is generally unnecessary for everyday usage.

The impact is further amplified by SQLite’s write patterns. Frequent insert-and-delete operations can generate significantly more physical SSD writes than the final database size would suggest, a phenomenon known as write amplification.

As a result, the actual storage wear may be considerably higher than users expect when looking only at the database file size.

Open Issue Remains Unresolved

OpenAI has recently released updates containing SQLite reliability improvements, but users report that those changes have not addressed the excessive write-rate problem.

At the time of writing, the GitHub issue remains open.

As a temporary workaround, Linux and macOS users can redirect the ~/.codex/logs_2.sqlite database to /tmp/, causing writes to be stored in RAM rather than on the SSD. This can dramatically reduce storage wear, although log data will be lost after a reboot.

In other OpenAI-related news, reports suggest the company is exploring the development of a social networking platform. Separately, claims have circulated online regarding Anthropic’s Mythos AI system and alleged cybersecurity testing results (report), although those reports remain unverified and should be treated with caution until independently confirmed.

Via NotebookCheck