Surfaces the GitHub issue showing Codex CLI writes terabytes to ~/.codex/log during normal sessions, with no rotation or size cap. Frames the bug as small in code terms but severe in impact because soldered Apple Silicon SSDs have finite TBW endurance budgets that this can burn through in a weekend.
Argues the real lesson isn't the missing log rotator — it's that agent loops re-serialize the entire context window (up to 200k tokens) on every turn, producing orders of magnitude more telemetry than the CLIs they're replacing. Traditional dev tools solved log rotation and verbosity defaults decades ago, and AI tooling is rediscovering those lessons the hard way.
Highlights that a 512GB NVMe is typically rated for 300-600 TBW over its warranty life, and Codex can plausibly consume a year of that endurance budget in a single weekend of heavy use. On machines with non-replaceable soldered storage, this turns a logging oversight into a permanent reduction in device longevity.
GitHub issue [openai/codex#28224](https://github.com/openai/codex/issues/28224) hit Hacker News at 197 points after a user noticed their MacBook's SSD was burning through write endurance at an alarming rate. The culprit: OpenAI's Codex CLI was writing terabytes of trace and debug data to local storage during normal interactive sessions. Not over weeks. Over hours.
The reproduction is trivial: install Codex, run a long-ish coding session with tool use enabled, then check `du -sh ~/.codex/log` — users are reporting directories north of 1 TB after a single afternoon. The logs contain full request/response payloads, including the entire transcript history re-serialized on every turn, plus tool-call traces, plus internal state dumps. There is no rotation policy, no size cap, and no documented flag to disable it.
The issue thread quickly accumulated reports from users on macOS, Linux, and WSL all seeing the same behavior. Several pointed out that on Apple Silicon laptops with soldered SSDs, this isn't just a disk-space annoyance — it's a hardware lifespan question. A 512GB NVMe drive is typically rated for 300-600 TBW (terabytes written) over its warranty life; Codex in its current state can plausibly consume a year of that endurance budget in a weekend of heavy use.
The fix is, on its face, embarrassingly small — wire up a log rotator, add a size cap, default the verbosity down a notch. The reason this is worth a serious editorial is that it exposes a category of failure that AI tooling is going to keep producing, and that traditional developer tools mostly stopped producing twenty years ago.
Agentic CLIs generate orders of magnitude more telemetry than the tools they're replacing, because every turn of the agent loop involves serializing the entire context window — sometimes 200k tokens — into a log line. If you naively `JSON.stringify(state)` on each step of a 50-step agent run, you've written roughly 10 MB of structured logs for what felt like a one-minute interaction. Multiply that by a workday and the numbers stop being theoretical. The same shape of bug almost certainly exists, latent, in half the agent frameworks currently shipping.
Compare the response to how older tooling treats this. `git` writes practically nothing to disk by default; you have to opt into `trace2`. `npm`'s debug log is one file, capped, and the path is printed in red the moment it's written. Even Chrome's V8 will refuse to dump heap snapshots without an explicit flag. The Codex bug isn't a logging mistake — it's an instance of the broader pattern where AI tools are being shipped with observability defaults inherited from server-side telemetry, deployed onto user laptops where those defaults are catastrophic.
The HN thread also surfaced a quieter concern: those log files contain full prompts. For anyone using Codex against a proprietary codebase, a 1 TB unencrypted dump of every line of source that was ever pasted into the agent is sitting in `~/.codex/log` waiting for the next backup sweep. Corporate security teams that approved Codex on the basis of OpenAI's enterprise data-handling promises did not, in any document anyone has seen, sign off on "and we'll also write all of it to disk in plaintext."
OpenAI engineers responded in the thread within hours and a patch is reportedly in review. That's the right speed. But the issue had been open and reproducible long enough that the question worth asking is why this didn't trip an internal canary first — presumably the people who built Codex are also dogfooding it on machines with disks.
Three concrete moves if you're running Codex CLI today or evaluating it.
First, check your own machine right now. `du -sh ~/.codex` on macOS and Linux, `Get-ChildItem $env:USERPROFILE\.codex -Recurse | Measure-Object -Property Length -Sum` on Windows. If the number is shocking, delete the log directory and either symlink it to `/dev/null` or mount a small tmpfs over it. The CLI keeps working — the logs are not consulted on subsequent runs, just appended to.
Second, audit every other AI CLI in your dev environment the same way. Cursor, Cline, Aider, Continue, Claude Code, Goose — anything with an agent loop is a candidate for the same failure mode. Most ship with a `--verbose` or `--debug` mode that is, in practice, the default once you've enabled tool use. The diagnostic is the same: find the cache/log directory, check size, look for whether there's a rotation config you missed.
Third, if you're shipping an agent tool yourself, treat "how much does this write to disk per turn" as a first-class metric, not an afterthought. A reasonable cap is 100 MB total, rotated, with the location printed at startup. Anything more aggressive than that and you owe your users an explicit opt-in flow. This is the kind of cross-cutting concern that's hard to retrofit and easy to design in — pick a logger that supports rotation and size limits out of the box (winston, pino with `pino-roll`, Python's `RotatingFileHandler`, Rust's `tracing-appender`) and configure it before you write a single `info()` call.
For enterprise security teams: this is also a moment to revisit whatever data-residency assurances your AI vendor gave you. "We don't train on your code" and "we don't log your code locally in plaintext" are different promises, and the second one is the one that just visibly failed.
The specific Codex bug will be patched within days; the broader pattern won't. Expect a quiet wave of similar disclosures over the next quarter as security researchers and curious users start running `du` against the home directories that AI tooling has been silently filling. The interesting second-order question is whether OS vendors start treating this as a platform problem — macOS and Windows could both surface "this app wrote 200 GB this week" the way they currently surface battery hogs, and right now they don't. Until they do, the burden falls on the people building agent tools to take disk I/O as seriously as they take API tokens. The Codex thread is a reminder that they mostly aren't.
Someone posted a temporary workaround for this on X[1].sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"Also, I found that running VACUUM FULL on the sqlite file on my laptop shrunk it from 27GB
Well, everyone's bashing on OpenAI as well they should, but just a reminder, unlike Claude Code, Codex is officially available to customize here: https://github.com/openai/codexIt's fairly easy to patch.
Shocking. Been open a week and AFAICT just silence from OpenAI. I just find it baffling. You'd think that these vendors would be very sensitive to this sort of issue. I mean, surely they have multiple agents hooked up to github monitoring potential issues and proposing fixes, right? ...right?Su
Vibe coding takes "move fast and break things" to a whole nother level.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Codex is one of the most infamous examples of slopware. Just having the window unhidden on my mac will cause it to use 100% of the GPU displaying the spinner message.THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!!So any time you're waiting on the model (which is 90% of the time), your