The editorial argues verbose logging eating disk is an ancient sysadmin trope, but AI agents change the blast radius because they generate orders of magnitude more I/O per minute than a human developer. A machine running flat out against a context window re-serializes huge payloads on every turn, turning a benign logging oversight into measurable SSD wear.
The original reporter framed the bug specifically in terms of terabytes written to SSDs — emphasizing wear rather than capacity. Follow-up commenters ran smartctl and calculated that a week of heavy Codex use could burn ~5% of a consumer NVMe's rated TBW endurance, making this a measurable shortening of hardware lifespan.
The editorial points out there is no rotation, no size cap, and in older builds no flag to disable logging at all. These are solved problems in every mature CLI tool, and their absence in a flagship OpenAI product suggests the agent tooling shipped without basic operational hygiene that Linux sysadmins have taken for granted for decades.
While OpenAI has acknowledged the bug and a fix is in flight, the editorial highlights that damage is already accumulating on SMART counters for early adopters. Practical mitigations — symlinking the log directory to /dev/null, mounting it on tmpfs, or redirecting to an external drive — are presented as necessary stopgaps rather than nice-to-haves.
On June 20, a user filed [openai/codex#28224](https://github.com/openai/codex/issues/28224) reporting that the Codex CLI had quietly written multiple terabytes of log data to their local SSD over a few days of normal agent use. The issue rocketed to 377 points on Hacker News within hours, with a long tail of replies from developers running `smartctl` against their own machines and finding the same pattern: tens to hundreds of gigabytes per session, climbing into the terabytes for anyone leaving Codex running an agent loop overnight.
The mechanism is mundane. Codex CLI writes a verbose session transcript — every tool invocation, every streamed token, every file the agent touches — to a log file under the user's home directory. There is no rotation, no size cap, and in older builds no flag to disable it. A long-running agent that reads large files, retries failed shell commands, or streams a 200K-context response will pump the entire payload to disk, often multiple times as the context window gets re-serialized on each turn. One commenter reported 1.8 TB written in 36 hours. Another, running on a 1 TB consumer NVMe rated for ~600 TBW, calculated that a week of heavy Codex use would burn through roughly 5% of the drive's total endurance.
OpenAI engineers acknowledged the bug within the issue thread and a fix is in flight, but the damage for early adopters is already on the SMART counters. The workaround in the interim is to symlink the log directory to `/dev/null`, mount it on tmpfs, or — on macOS — point it at an external drive you don't mind chewing through.
This is not a novel category of bug. Verbose-logging-eats-disk has been a Linux sysadmin punchline since syslog shipped. What's new is the blast radius: an AI coding agent generates orders of magnitude more I/O per minute than a human developer, because the inner loop is a machine running flat out against a context window, not a person typing. A `tail -f` on a Codex session log scrolls faster than you can read. Multiply that by an 8-hour agent run and the math gets ugly fast.
The deeper issue is that consumer SSDs were never sized for this workload. A typical 1 TB NVMe ships with 600 TBW (terabytes written) of rated endurance — enough for roughly 5 years of normal developer use, which assumes maybe 100–300 GB written per day across compiles, Docker images, and browser cache. Agent workloads invert that math. If your coding assistant writes 50–200 GB per session and you run three sessions a day, you're burning a year of drive endurance per month. The drive won't fail immediately — modern NAND degrades gracefully — but the warranty clock is moving 10x faster than the manufacturer modeled.
This matters beyond Codex specifically. Claude Code, Cursor's background agents, Aider, Continue.dev, and the rest of the agentic-CLI cohort all keep some form of session transcript for debugging and replay. Most have better defaults than what shipped in Codex CLI — Claude Code rotates and caps its logs, Cursor stores most state server-side — but none of them were designed assuming the user would leave them running 24/7 against a 200K context. The Codex bug is the first public data point on what happens when that assumption breaks. It will not be the last.
The community reaction on HN split predictably. One camp called it a rookie mistake — "you ship a CLI in 2026 without log rotation?" Another pointed out that verbose logs are exactly what you want when an agent silently does something destructive, and the real fix is structured, queryable session storage (SQLite, DuckDB) rather than append-only text. A third camp, mostly hardware people, asked the question nobody at the model labs seems to be asking: what's the hardware profile of a developer machine that runs agents as its primary workload, and does any laptop shipped before 2025 actually meet it? The answer for the average MacBook Pro M2 with a soldered 512 GB SSD is probably "no."
Three concrete actions for anyone running an agentic CLI today.
First, audit your wear. On Linux, `sudo smartctl -a /dev/nvme0` shows `Data Units Written` (multiply by 512,000 to get bytes) and `Percentage Used`. On macOS, `system_profiler SPNVMeDataType` exposes a similar field, or run `smartctl` via Homebrew. If `Percentage Used` jumped meaningfully in the last month and the only thing that changed is your AI tooling, you've found your culprit. The drives most at risk are 256–512 GB consumer NVMes in laptops, which ship with the lowest TBW ratings (~150–300 TB) and no easy replacement path on soldered models.
Second, redirect or cap your agent logs. For Codex CLI specifically, the interim workaround per the GitHub thread is to symlink `~/.codex/logs` to `/dev/null` or to a tmpfs mount. For other agents, check the docs for a log-level flag or a config to set retention. If your agent writes to `~/Library/Logs` on macOS, you can swap that for a path on an external SSD where you don't care about wear.
Third, rethink where agent state lives. If you're building anything that wraps an LLM in a loop — a custom CI agent, a code-review bot, a long-running research agent — assume the default verbose-log-to-local-disk pattern is wrong. Session transcripts belong in object storage (S3, R2) or a managed database, with the local disk holding only what you need for the current turn. The Codex bug is a free lesson in what happens when you skip that design decision.
The Codex fix will ship in a point release and the issue will close. The structural problem won't. Agentic developer tools are entering a phase where the constraints that bound "a developer's machine" for 30 years — RAM, CPU, network — are being joined by a new one: write endurance. Expect a wave of "agent-aware" hardware guidance over the next year: minimum TBW ratings in tool docs, recommended external scratch disks, maybe even a return to the discipline of putting `/var/log` on its own partition. The first generation of agent CLIs shipped assuming a human's I/O pattern. The second generation will have to assume a machine's. The drive in your laptop is the first thing that will tell you which generation you're running.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.