A logging bug in OpenAI’s Codex CLI is writing approximately 640 terabytes per year to users’ solid-state drives — enough to consume a typical consumer SSD’s entire write endurance warranty in under 12 months. Developer Rui Fan, a project management committee member of Apache Flink, reported 37 TB of writes in just 21 days of normal use. OpenAI has confirmed engineers are working on a fix, but the bug may have already cost users low-single-digit millions of dollars in drive wear during the March–June window.
🔍 THE BOTTOM LINE
The Codex CLI’s local diagnostic logging — on by default since the tool’s debut — writes SQLite feedback logs continuously and without throttling. One developer’s machine accumulated 37 TB in 21 days, extrapolating to ~640 TB/year. A Samsung 990 Pro 1TB SSD is rated for 600 TBW (terabytes written). The math is simple: the bug can burn through a drive’s warranty in under a year. OpenAI says fixes are in progress via recent pull requests, but the issue has been surfacing in the project’s GitHub repo for months.
The Bug That Burns Drives
The problem lives in Codex’s local diagnostic logging, which was introduced when the CLI tool debuted and is enabled by default. The logs stay on the device unless included by the user in a feedback report — but the logging itself runs continuously, writing to a SQLite database without regard for the cost.
According to The Register, the bug report opened last week on GitHub issue #28224 warns in its title: “Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance.”
“On my machine, after about 21 days of uptime, the main SSD has written about 37 TB,” wrote Rui Fan. “Process/file-level checks show Codex SQLite logs are the main continuous writer. That extrapolates to roughly 640 TB/year. On a 1 TB SSD, that is about 640 full-drive writes per year. Some consumer SSDs are rated around 600 TBW, so this could consume roughly a full drive’s warranted write endurance in less than a year.”
The Math Behind the Damage
SSDs have a finite lifespan measured in terabytes written (TBW). Samsung’s 2025 9100 PRO 1TB SSD, for example, promises 600 TBW. After that point, performance degrades and failure becomes more likely.
Another developer in the GitHub thread reported that Codex itself analyzed the disk usage and estimated the bug cost $38.64 in drive value on a Samsung 990 2TB NVMe. The Codex-generated assessment of the overall cost: “This regression plausibly burned low-single-digit millions of dollars of SSD endurance across users during the March-June window.”
The cost calculation assumes $0.13 per TB written, based on the formula: TB written × (SSD price / SSD TBW). For a 1TB SSD at $200 with 600 TBW, that’s $0.333 per TB — making the estimate conservative for higher-end drives.
OpenAI’s Response
A spokesperson for OpenAI confirmed to The Register that company engineers are aware of the problem and are working to fix it — something evident from several recent pull requests intended to address the issue. The logs are intended to help OpenAI engineers diagnose issues, and the problem appears to be in the implementation rather than the intent.
Concerns about excessive write operations have been surfacing in the project’s GitHub repository for several months, suggesting the fix took longer than it should have to surface. According to Notebookcheck, the bug could kill a consumer SSD in under a year of normal Codex usage.
NZ Angle
For New Zealand’s growing community of independent developers and small studios, this bug presents a real financial risk. Kiwi freelancers whose primary work tool is their laptop may be silently wearing out their SSDs without realising it. NZ electronics prices are already inflated by import costs — replacing a prematurely burned-out 2TB NVMe drive costs $300-500 locally versus $200 in the US.
Developers running Codex CLI should check their SSD wear using smartctl -a /dev/nvme0n1 (installable via Homebrew) and consider disabling local diagnostic logging until the fix ships.
The Bigger Picture
The bug highlights a broader problem with AI coding tools: the infrastructure code around the model often gets less scrutiny than the model itself. OpenAI excels at model intelligence, but the CLI wrapper — the tool developers actually run on their machines — shipped with a logging implementation that writes hundreds of terabytes a year. As AI coding agents like Codex, Claude Code, and others become embedded in daily development workflows, the resource cost of running them locally matters. CPU, memory, and disk I/O are not free — and when a tool silently consumes 640 TB/year of write endurance, the hardware cost becomes part of the AI tax.
❓ FAQ
How do I check if my SSD is affected?
On macOS, use smartctl -a /dev/nvme0n1 (via Homebrew: brew install smartmontools) to check Total LBAs Written. On Linux, check /sys/class/block/nvme0n1/device/life_time. If you’ve been running Codex CLI daily, compare your wear levels against the drive’s rated TBW.
Is this a hardware bug or a software bug? Software. The Codex CLI’s SQLite logging writes continuously without throttling. The SSD is just doing its job — the tool is asking it to write far more data than necessary.
Will OpenAI compensate users for drive wear? No compensation has been announced. OpenAI has confirmed a fix is in progress via recent pull requests. The estimated cost across all users is in the low-single-digit millions.
Should I stop using Codex CLI? If you’re running it daily on a machine with an SSD you care about, at minimum check your drive wear. You can also look for recent Codex updates that may include the logging fix. The issue has been open on GitHub for months — the fix should be imminent.
🔍 THE BOTTOM LINE
A logging bug that writes 640 TB/year to users’ SSDs is the kind of infrastructure oversight that erodes trust in AI coding tools. OpenAI is fixing it, but the months-long gap between the first GitHub reports and the fix suggests that the local experience of running AI tools — the actual hardware cost on developers’ machines — is being treated as a secondary concern. As AI agents become default development tools, the resource footprint matters. Your SSD is not free, and a tool that silently burns through its warranty is a tax on every developer using it.
