OpenAI Codex CLI Bug May Be Wearing Out SSDs With Excessive Disk Writes
A bug in OpenAI’s Codex CLI could be putting unnecessary strain on solid-state drives, especially for users who leave the tool running for long periods. The issue involves excessive diagnostic logging that writes huge amounts of data to a local SQLite database, potentially consuming a large portion of an SSD’s rated lifespan far faster than expected.
The problem was reported after a user noticed unusually high disk activity on their system. After investigating, they found that Codex was repeatedly writing logs to a local database file stored at ~/.codex/logs_2.sqlite. In one case, the machine recorded roughly 37 TB of writes over just 21 days of uptime. If that rate continued for a full year, it would amount to around 640 TB of writes.
That figure matters because many consumer SSDs, especially 1 TB models, are commonly rated for about 600 TBW, or terabytes written, across their warranted lifetime. In simple terms, this bug could theoretically burn through a typical drive’s warranty-rated endurance in under a year if Codex CLI is left running continuously.
The issue appears to come from an overly aggressive logging setup. Codex’s SQLite feedback logging system is reportedly running at the global TRACE level by default, which is the most verbose logging level. Instead of recording only important errors or useful diagnostic information, it logs a flood of low-level activity, including raw WebSocket payloads and ordinary filesystem events.
For most users, this kind of TRACE-level logging offers little practical value. According to the original report, around 71% of the stored log data falls into this noisy TRACE category. Worse, the logging behavior does not appear to respect the standard RUST_LOG environment variable, meaning users do not have an obvious built-in way to reduce the log level.
The impact is not limited to the visible size of the SQLite database. Because of how the database is being updated, Codex may be performing tens of thousands of insert-and-delete operations per minute. This creates write amplification, where the SSD ends up physically writing far more data than the database file size alone would suggest.
That makes the bug more concerning for developers, power users, and anyone running Codex CLI as part of a long-running workflow. SSDs are designed to handle heavy workloads, but unnecessary constant writes can still reduce drive endurance over time, especially on consumer-grade hardware.
Reports of related logging and SQLite behavior have reportedly appeared in different forms for months. While some reliability improvements involving SQLite have been mentioned in recent updates, the excessive write-rate issue itself has not yet been fully resolved and remains open.
For now, Linux and macOS users who are concerned about SSD wear have a temporary workaround. The Codex log database file at ~/.codex/logs_2.sqlite can be redirected to /tmp/, which typically stores temporary files in memory or a less persistent location depending on the system configuration. Since the file does not contain conversation data, losing it after a reboot should not affect user chats or important work.
This workaround can help reduce unnecessary SSD writes while waiting for an official fix. However, it is not a permanent solution. Ideally, Codex CLI should lower its default logging level, respect standard logging controls, and avoid writing large volumes of low-value diagnostic data to disk.
Until that happens, users running OpenAI Codex CLI should keep an eye on disk activity and SSD write totals, particularly if the tool stays active for days or weeks at a time. What looks like a background logging issue could quietly become a real hardware endurance problem.
