By ByteBot
If you’ve had OpenAI Codex running for more than a few weeks, your SSD has absorbed far more writes than you’d expect from a year of normal development work. A bug discovered by GitHub user @1996fanrui shows that Codex’s SQLite feedback log — stored at ~/.codex/logs_2.sqlite — writes at a rate that extrapolates to roughly 640 terabytes per year. On a typical 1 TB consumer SSD rated for ~600 TBW lifetime, that’s enough to burn through the drive’s entire warranted endurance in under twelve months.
The Hacker News thread hit 354 points and 193 comments within hours of the report going public. The GitHub issue (#28224) remains open, with no assignee and no milestone as of June 22, 2026. A workaround exists. Use it.
How 640 TB/Year Happens
The root cause is a single misconfiguration: Codex’s SQLite logging sink ships with global TRACE level enabled by default. TRACE is the noisiest verbosity setting — it captures everything, including raw WebSocket payloads, internal tokio-tungstenite events, and messages like "idle interval checking for expired". About 70% of logged bytes are TRACE; another 25% are redundant OpenTelemetry mirror events. In total, 96% of what Codex writes to your SSD has zero diagnostic value for a regular user.
The damage compounds because of how SQLite operates in WAL mode. Codex doesn’t just write once — it inserts rows, prunes them, inserts again. The database retains roughly 680,000 rows, but the AUTOINCREMENT counter shows 5.5 billion total IDs: a gap that proves roughly 4.8 billion rows have been inserted and deleted. A single 50-token response generates more than 5,000 database inserts. This insert-and-prune churn creates write amplification at the flash layer, so actual flash writes dwarf the apparent file size. One user documented 37 TB written in 21 days. Another’s WAL file was writing at 5 MB/s during active use. On Windows WSL2, the symptom is 100% disk activity — which is often how users first notice something is wrong.
One more detail worth knowing: setting RUST_LOG=warn does nothing. The SQLite sink bypasses Rust’s standard logging filter entirely. This is not documented anywhere.
Fix It Before the Patch Arrives
Two workarounds exist right now. First, check how large your log file already is:
ls -lh ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal 2>/dev/nullThe simpler fix redirects the log file to RAM so no persistent SSD writes occur:
# Stop Codex / VSCodium first, then:
rm ~/.codex/logs_2.sqlite
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqliteOn reboot the symlink’s target disappears, Codex creates a fresh file in RAM, and the cycle repeats — no persistent writes. You lose nothing important: logs_2.sqlite contains only internal diagnostics. Your conversations and session state live in state_5.sqlite, which is not affected by this bug.
The second option is more surgical. Connect with sqlite3 and create a trigger that silently drops all inserts into the logs table:
CREATE TRIGGER block_log_inserts
BEFORE INSERT ON logs
BEGIN SELECT RAISE(IGNORE); END;If you’ve already accumulated a large log file, run sqlite3 ~/.codex/logs_2.sqlite "VACUUM;" to reclaim space. One user shrank their 27 GB database to 73 MB with a single VACUUM.
OpenAI Knew in April
This is where it gets uncomfortable. GitHub issue #17320 — documenting the identical WAL write problem — was filed on April 10, 2026. That’s more than two months before the current report went viral. OpenAI’s changelog has referenced “SQLite stability improvements” in the interim, but the write rate problem was never addressed. There are now at least ten related GitHub issues tracking variants of the same bug. Issue #29237 documents that when logs_2.sqlite grows past 200 MB, Codex crashes with a SIGTRAP — which means this will eventually surface on its own, whether or not you’re watching your disk usage.
QA misses happen in fast-moving tools. But shipping TRACE-level logging to 3 million weekly users — and leaving it unfixed for two months after it was reported — is a specific kind of failure. Debug settings belong in CI, not in users’ home directories.
Track the Fix
Watch GitHub issue #28224 for the official patch. When it lands, update Codex and remove the symlink workaround. Until then, the tmpfs redirect costs you nothing and protects your hardware. Apply it now.
