Nothing breaks. That is what makes this one nasty. The build passes, Codex answers, the disk still shows free space, and underneath all of it a hardware budget you never charted is draining. Per GitHub issue #28224 filed against openai/codex, one instance left running wrote about 37 TB across 21 days of uptime. Extrapolated, that is roughly 640 TB a year. A typical consumer NVMe drive is warranted to around 600 TBW for its entire service life. So Codex can spend a drive's rated endurance in under twelve months while doing nothing you actually asked it to do.
The bug is a logging default, not a crash
The mechanism is boring, which is precisely why it slipped through. Codex ships a SQLite feedback log sink wired to a global TRACE default. Issue #28224 traces it to Targets::new().with_default(Level::TRACE), the loudest setting available, persisted to ~/.codex/logs_2.sqlite alongside its -wal and -shm companion files. In the reporter's sample, TRACE-level lines account for 70.7% of retained bytes. Fold in the two OpenTelemetry categories (codex_otel.log_only and codex_otel.trace_safe) and about 96% of the volume is data no end user will ever open.
What is actually in there: raw WebSocket payloads, routine filesystem events, the agent opening passwd and ld.so.cache. This is telemetry for the vendor, shipped at full verbosity onto your machine. A "feedback log" that, measured in flash endurance, behaves like a slow attack on your hardware.
