OpenAI Codex logging may burn millions in SSD endurance through 640 TB/year

OpenAI’s Codex may have quietly been turning solid state drive life into write-cycle collateral. The bug report filed in OpenAI’s Codex GitHub repo warns that “Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance #28224.” And a developer, Rui Fan, says that on his machine, after about 21 days of uptime, the main SSD had written about 37 TB, with process and file-level checks showing Codex SQLite logs as the main continuous writer. If that extrapolation holds, the story is not about a small annoyance. It is about SSDs reaching their rated write endurance far faster than users reasonably expect.

The numbers are blunt. If Codex writes roughly 640 TB per year, then on a 1 TB SSD that translates to about 640 full-drive writes per year. Some consumer SSDs are rated around 600 TBW, meaning total bytes written endurance. The source also grounds this with a specific example: Samsung’s 2025 9100 PRO SSDs promise 600 TBW for the 1 TB SSD, and after that threshold performance can degrade and failures become more likely. Another developer in the same discussion says Codex “analyzed the disk usage and says this bug cost me $38.64 in drive value of my Samsung 990 2 TB NVMe.” That same thread references Codex’s own economic impact estimate that a regression “plausibly burned low-single-digit millions of dollars of SSD endurance across users during the March-June Window.”

So how does a piece of developer tooling end up as a hardware endurance problem? SSDs have a finite lifespan that is often measured in terabytes written (TBW). That number varies by model and capacity, so the same amount of logging can be trivial on a high-endurance enterprise drive and brutal on a mainstream consumer stick. The logic used in Codex’s cost assessment is explicitly spelled out: cost per TB written to SSDs is computed with a formula based on TB written multiplied by (SSD price / SSD TBW). For a 1 TB SSD, the example yields $12.33 for 37 TB of wasted storage. The article also shows how a more spacious, higher TBW SSD would soften the per-byte cost: $0.25 per TB for a $300 / 1200 TBW 2 TB Samsung 9100 PRO SSD. Translation: even if the total write volume is the same, the economic pain distribution depends on what hardware users bring to the party.

What makes this especially uncomfortable for a company shipping an AI coding agent is that this is not necessarily a model problem or an efficiency problem. It is a logging implementation problem. The logs involved are local diagnostic logging, introduced around the time the app debuted last year and also on by default. The logs stay on the device unless included by the user in a feedback report. In December 2025, Codex devs announced plans to add telemetry by default (except where disallowed by law) to the Codex CLI, but this issue is tied to local diagnostic logging, not the later telemetry plan. In other words, users may have been unknowingly carrying a constant write workload on their own machines simply because logging was enabled by default.

The OpenAI response described in the source is that engineers are aware and working on it, and that pull requests intended to address the problem have been landing, with progress still leaving users filing additional issues. A spokesperson confirmed engineers are aware of the problem. The explanation provided to the reporter: the logs are intended to help OpenAI engineers diagnose issues, and the problem resulted from high-volume data being stored in a way that created far more disk activity than anticipated. The issue appears to date back to work done in February that wrote app-server SQLite logs at TRACE level. TRACE level is more verbose than ERROR level, and the article notes that Codex, presumably running GPT-5.3, reviewed this series of commits. That detail is the part that makes people raise an eyebrow: if the agent is intelligent enough to review code, why did the logging end up so write-heavy?

For decision-makers, the second-order implications go beyond one bug report. First, SSD wear is a user-visible reliability issue that can translate into device replacements or earlier failures, which can become a reputational flywheel. Second, logging volume is a governance question. Even if logs are for debugging, default-on behavior interacts with privacy and compliance expectations. The source notes telemetry plans by default for the CLI (with legal exceptions), which puts more pressure on building a clear separation between useful diagnostics and anything that unnecessarily stresses infrastructure. Third, there is the procurement reality: enterprises and power users often standardize on storage classes with known endurance. A tool that burns write cycles at scale could become a cost center that IT teams do not budget for, even if the tool is “just writing logs.”

For peers in AI tooling, the strategic stake is simple: if diagnostic logging can be an endurance tax, then cost controls are not optional. This case shows that even a well-intentioned feedback system can become expensive when it is implemented at the wrong verbosity level, stores high-volume data inefficiently, and runs continuously on end-user hardware. OpenAI is trying to fix it, but until the write pattern is corrected and validated in the wild, the credibility of the entire “agent that helps developers” promise takes a hit. When your product is measured in throughput and user trust, the hardware under the hood matters.