OpenAI Codex has been linked to a local SQLite feedback log issue that wrote 37 TB in 21 days, equal to about 640 TB on an annualized basis. That figure exceeds the 300 to 600 TBW endurance range commonly cited for mainstream consumer SSDs, putting drive lifespan under pressure if the behavior continues unchecked.
The issue was disclosed this month by GitHub user @1996fanrui. After noticing abnormal disk consumption during normal Codex use, the user traced the problem to a local SQLite database. The file itself occupied about 1.2 GiB and stored roughly 506,149 rows, yet the historical row ID had climbed to 5.5 billion. That gap suggests old records were being removed, but new writes were arriving far faster than cleanup could keep up.
TRACE logs and telemetry mirroring drove the write volume
According to the source material, TRACE-level logs made up 70.7% of the total, while OpenTelemetry mirrors accounted for 25.3%, with the rest at 3.9%. TRACE is the most granular logging level and is generally not expected to persist continuously to local storage in a production environment.
Four channels were identified as the main contributors: WebSocket event logging, inotify filesystem notifications, internal logs from dependency packages, and OpenTelemetry telemetry mirroring. Codex reportedly recorded low-level WebSocket activity into SQLite, including events generated at high frequency. It also wrote inotify events tied to working-directory changes. TRACE logs from third-party dependencies were captured and persisted as well. On top of that, telemetry data prepared for remote upload was also copied into the local SQLite database.
Two fixes were merged, but not all write activity was removed
The reported fix came through two pull requests. PR #29432 stopped logging every WebSocket event, and PR #29457 filtered high-frequency targets. OpenAI said the combined changes removed about 85% of the problematic write volume.
That still leaves a tail. Using the same annualized baseline from the report, the remaining 15% comes to about 96 TB per year. It is far below the original rate, though still material for consumer SSDs.
Lack of user visibility became a central concern
The source argues that the deeper issue was not just a bad logging configuration, but the fact that users were not clearly informed. The behavior came to light only after abnormal disk usage was noticed and investigated manually. Without that kind of monitoring, local writes at this scale could continue until storage fills up or hardware endurance is consumed.
The report also connects the local OpenTelemetry copy to privacy and compliance questions. In regulated sectors such as finance, healthcare, and legal services, or in high-sensitivity environments, the existence of a local telemetry mirror may itself require scrutiny. The issue was closed 8 days after discovery, which points to a relatively quick response, but the remaining write volume and the absence of proactive notice remain unresolved concerns in the discussion.