OpenAI's Codex Is Silently Destroying Your SSD — 640 Terabytes a Year
A routine check of disk write counters. A number that shouldn't be possible. After just 21 days of running OpenAI's Codex, one developer watched their SSD absorb 37 terabytes of writes — not from video rendering or database migrations, but from a background logging system gone catastrophically wrong.
Extrapolated annually: ~640 TB written to your drive. For context, a typical consumer SSD has a rated write endurance of 300–600 TBW (terabytes written). Codex can exhaust it in under a year, silently, while you're just using an AI coding tool.
What's Actually Happening Inside the Database
The bug lives in Codex's SQLite-based feedback logging system. A GitHub issue filed against the repository lays out the forensics in brutal detail.
The database had allocated 5.5 billion row IDs while retaining only 506,000 rows — a 10,000× gap that tells the whole story. Rows are being inserted and pruned in a continuous churn. In a 15-second measurement window, 36,211 rows were inserted while the retained count stayed flat.
The breakdown of what's being logged:
- 70.7% TRACE-level logs — the noisiest, lowest-value tier, including dependency internals, tokio-tungstenite events, and raw inotify filesystem notifications
- 25.3% OpenTelemetry mirroring — duplicating telemetry data that's already being sent elsewhere
- The remainder: raw WebSocket and SSE payload bodies
All of this at the default log level. No configuration change needed. Every installation ships this way.
The proposed fixes are straightforward: eliminate global TRACE defaults for SQLite sinks, filter dependency noise, store payload summaries instead of raw bodies, deduplicate telemetry, and add a database size cap. None of these are architecturally complex. The issue is open and unassigned.
The Hacker News Verdict: "Slopware"
When the story surfaced on Hacker News, the technical outrage was expected. What emerged alongside it was something sharper: a diagnosis.
Commenters coined the term "slopware" — software whose quality has degraded because AI-generated code was used to build it without sufficient human review. The accusation lands particularly hard when the product in question is itself an AI coding assistant.
The SSD logging bug wasn't alone in the indictment:
- GPU usage spikes from idle spinner animations
- Memory leaks consuming 60+ GB of RAM during normal sessions
- Sluggish, unpredictable performance that users describe as getting worse over time
- Inadequate warnings before destructive file operations
One commenter shared a production incident where AI-generated code, lacking any understanding of transactional guarantees, caused data corruption. It passed review. It passed tests. It failed in production.
The counter-argument — that human-written software has always had these problems — didn't land well. The bar being compared against isn't average software. It's the tool that's supposed to raise the bar.
The Meta-Irony Problem
There's a specific kind of embarrassment available when an AI coding tool is visibly built with poor engineering practices. It's not just a bug report — it's a signal about the development process that produced it.
A TRACE-level default on a SQLite write path is the kind of thing a code reviewer catches. It's the kind of thing static analysis flags. It's the kind of thing you find in a pre-merge checklist. The gap between 5.5 billion allocated IDs and 506,000 retained rows is not subtle — it's a number that screams in any monitoring dashboard.
The fact that it shipped, and persisted for weeks while drives were being worn down, raises a question the community is now openly asking: are the teams building AI development tools actually using disciplined software engineering practices to build them?
This matters beyond reputational awkwardness. Developers are being asked to trust these tools with production codebases, sensitive credentials, and irreversible file operations. The trust model requires that the tool itself be held to a high standard.
What Developers Should Do Right Now
If you're running Codex, check your SSD write counters immediately. On Linux: sudo smartctl -a /dev/nvme0 — look at the "Data Units Written" field. On macOS: diskutil info disk0 and check Disk Write Bytes.
A temporary mitigation involves SQLite triggers to block new log entries, though this is a workaround, not a fix. Watch the GitHub issue for an official patch.
More broadly: monitor your AI tooling the same way you'd monitor any always-on background process. They're not passive text editors. They run persistent processes, maintain local databases, and make system calls continuously.
The Larger Takeaway
The logging bug will get fixed. It's a tractable engineering problem with a clear solution and a motivated reporter.
The harder problem is cultural. The HN discussion reflects a growing unease: that the speed pressures of AI-era development are producing tools that skip the unglamorous work — the careful defaults, the write amplification analysis, the "what happens on a 3-year-old laptop with a budget SSD" testing.
AI coding assistants are being marketed as a way to ship faster and with fewer defects. That promise is undercut every time the tool itself ships a defect of this magnitude.
The developers using these tools deserve better. And frankly, so does the case for AI-assisted development.
Sources: GitHub issue #28224 — openai/codex · Hacker News discussion