Codex's TRACE-by-Default Logging Is Quietly Eating SSDs OpenAI's Codex CLI tool writes up to 640 TB per year to SSDs due to a default TRACE-level logging configuration, causing rapid wear on consumer drives. A developer reported 37 TB written in 21 days, with the issue traced to a SQLite feedback-log sink that logs all dependency chatter. The problem has persisted for months, potentially destroying hardware by exhausting SSD write endurance. Dev Tools https://www.devclubhouse.com/c/dev-tools News Codex's TRACE-by-Default Logging Is Quietly Eating SSDs A global TRACE log sink in OpenAI's CLI can write hundreds of terabytes a year to a local SQLite file — and it's been festering for months. Priya Nair https://www.devclubhouse.com/u/priya nair Here's a failure mode you don't usually associate with an AI coding assistant: it slowly destroys your hardware. According to a GitHub issue against OpenAI's Codex https://github.com/openai/codex , the CLI's local feedback-logging database can write on the order of 640 TB per year to a developer's SSD — quietly, in the background, with no error, warning, or visible disk bloat to tip you off. One reporter clocked 37 TB written in 21 days of uptime , traced almost entirely to Codex's SQLite logs. That's not a corner-case crash. That's a default configuration burning through the warranted write endurance of a consumer drive in well under a year. And the root cause is the kind of one-line decision that any of us could have shipped on a tired Friday. A global TRACE default, plus write amplification The mechanism is mundane and that's exactly why it's worth your attention. Codex installs a SQLite https://www.sqlite.org feedback-log sink configured with a global default of Level::TRACE : Targets::new .with default Level::TRACE That single with default Level::TRACE persists everything — not just Codex's own events, but the TRACE chatter of every dependency in the tree. The reporter's breakdown is brutal: TRACE accounts for ~71% of retained log bytes, and the single noisiest source is raw websocket payload logging from the responses endpoint at 527 MiB. Add mirrored OpenTelemetry events codex otel.log only and codex otel.trace safe and you've explained roughly 96% of the volume before you've logged a single thing a human would ever read. pie title Retained log bytes by level single-machine sample "TRACE" : 70.7 "INFO" : 25.7 "DEBUG" : 3.0 "WARN" : 0.6 The content is pure noise. The top TRACE source by frequency is inotify filesystem events — 128,764 hits for ld.so.cache being opened, tens of thousands more for locale.alias , passwd , nsswitch.conf . Underneath that sits tokio-tungstenite's internal poll read / poll next plumbing logged line by line. None of this helps debug a coding session; it's the runtime's own breathing, written to disk forever. But the retained database size — about 1 GiB — is a lie about the real write volume, and this is the part developers should internalize. In a 15-second window the reporter saw ~36,211 rows inserted while the retained row count stayed flat at 681,774. The max row ID had already passed five billion . Codex is running a continuous insert-index-WAL-then-prune cycle: it writes rows, updates indexes, flushes to the write-ahead log, then deletes them to stay under a retention cap. The on-disk footprint looks innocent. The flash underneath is being hammered. That's textbook write amplification, and it's why a 1 GiB database can represent terabytes of physical writes. Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts. https://www.devclubhouse.com/go/ad/12 Why "it's just logs" is the wrong reflex If your instinct is "logs are cheap," that instinct was calibrated on spinning rust. NAND flash doesn't work that way. SSDs are rated in TBW — terabytes written — because each cell tolerates a finite number of program/erase cycles. A typical 1 TB consumer drive carries a warranty around 600 TBW . At 640 TB/year, Codex alone would spend that entire endurance budget in roughly twelve months, equivalent to ~640 full-drive overwrites in a year. Laptops with soldered, non-replaceable SSDs make that an expensive lesson. The deeper smell here is architectural, and it's common across the new wave of agentic dev tools: telemetry that was designed for a server fleet gets shipped to run permanently on a developer's laptop. On a backend you'd ship TRACE spans to a sampled collector with retention policies and you'd never blink. Mirror that same firehose into a local embedded database with a tight retention window and you've built a perfect write-amplification engine. OpenTelemetry's own SDK logs showing up twice in the top sources — once via log only , once via trace safe — is the tell that nobody costed out what "persist all targets at TRACE" means on an endpoint device. There's also a privacy wrinkle worth flagging: the reporter deliberately omitted the raw websocket/SSE payload samples because they can contain private conversation content. So the default behavior isn't only writing terabytes — it's writing your prompts and model responses to an unencrypted local SQLite file by default. OpenAI's own troubleshooting guidance https://developers.openai.com/codex/app/troubleshooting already warns users to scrub logs for sensitive information before sharing them, which is a tacit acknowledgment of what ends up in there. What to actually do about it This isn't a freshly discovered one-off. A near-identical report issue 22444 and threads in OpenAI's own developer forum describe the same SQLite trace flood filling disks "ever since a few versions ago," with at least one user maintaining a homegrown bash script to nuke the WAL and kill the process. When multiple independent reporters and an open PR are converging on the same SQLite sink, treat it as a real, reproducible defect rather than one weird machine. Concrete steps if you run Codex CLI: Check whether it's happening to you. The files live at ~/.codex/logs 2.sqlite , plus the -wal and -shm sidecars. A continuously growing WAL while Codex idles is your signal. ls -la ~/.codex/logs 2.sqlite watch the row id climb over a few seconds sqlite3 ~/.codex/logs 2.sqlite 'select max rowid from / your log table /;' Watch physical writes, not file size. The on-disk DB stays ~1 GiB; the damage is in cumulative writes. On Linux, track per-process or per-device write bytes iostat , /proc/