June 22, 2026
Logs out, drama in
Codex logging bug may write TBs to local SSDs
Users say Codex is chewing through SSD life while the comments section absolutely loses it
TLDR: A reported Codex bug may be writing absurd amounts of background data to local storage, potentially shortening the life of some SSDs. The comments instantly turned savage, with users blaming weak review, “slopware,” and AI-driven development habits for the mess.
A bug report about Codex quietly hammering a computer’s storage has turned into a full-on community roast. The claim is eye-popping: one user says Codex’s local log files kept writing so much data in the background that their main drive racked up 37 terabytes of writes in 21 days. In plain English, that means the app may be wearing out a laptop or desktop drive far faster than people expect, all because it’s obsessively saving mountains of internal chatter to local files. The technical details point to extremely chatty debug-style logging, with the report arguing that filtering a few noisy categories could cut almost all of the bloat.
But the real fireworks are in the reactions. One camp is asking the obvious and brutal question: how did this make it through review? Another goes even harder, calling Codex “slopware” and piling on with a side complaint that even its loading spinner allegedly sends a fancy MacBook into a fan-spinning meltdown. That turned the thread from “serious bug report” into “everything wrong with modern AI tools” group therapy. There’s also a mini civil war over whether this is just one bad bug or proof of a deeper problem with AI-assisted development. One commenter gagged at “obviously AI generated comments” in code reviews, while another dryly suggested that if huge temporary logs are truly needed, they belong in memory, not on your expensive drive. In other words: the storage bug is bad, but the comment-section trust crisis is the juicier story.
Key Points
- •The article alleges that Codex continuously writes large amounts of data to a local SQLite feedback log database under `~/.codex/`.
- •A reported system showed about 37 TB of SSD writes over roughly 21 days, and the article extrapolates that to around 640 TB per year.
- •TRACE logs account for about 70.7% of retained bytes in the sampled database, while `codex_otel.log_only` and `codex_otel.trace_safe` add another 25.3%.
- •The largest logged sources cited include websocket response logging, OpenTelemetry mirror logs, generic TRACE logs, transport logs, and SSE response logs.
- •A 15-second sample showed the maximum row ID rising by about 36,211 rows, which the article presents as evidence that actual write volume exceeds the retained database footprint.