Codex Logging Bug Can Write Terabytes to Your SSD

OpenAI's Codex CLI has a bug that writes excessive diagnostic logs to a local SQLite database, potentially consuming terabytes of SSD write endurance. The GitHub issue has been open for over a week with no official response from OpenAI.

The bug hit Hacker News this morning and the community reaction has been pointed.

The Bug

Codex continuously writes trace-level logs to ~/.codex/logs_2.sqlite and its associated WAL/SHM files. The logging is indiscriminate - it captures everything from low-value dependency logs (inotify events, locale lookups) to raw websocket payloads and OpenTelemetry diagnostic events.

By the numbers:

• Extrapolated write rate: ~640 TB/year
• One user reported ~37 TB written after 21 days of uptime
• TRACE-level logs account for approximately 71% of retained log bytes

The problem is compounded by write amplification in the SQLite database. Users report approximately 36,211 rows inserted per 15 seconds while the retained row count remains static - a continuous insert-and-prune cycle that multiplies actual disk writes.

A 1 TB SSD with 600 TBW (terabytes written) endurance rating could theoretically be worn out in less than a year of continuous Codex usage.

Root Cause

The SQLite feedback log sink uses a "global TRACE default" configuration. This means every log target writes at maximum verbosity regardless of importance. The fix is straightforward - switch from global TRACE to targeted INFO-level logging for core Codex modules. Community members estimate this would reduce logged bytes by approximately 96% without disabling diagnostics entirely.

Multiple developers have prepared pull request branches with proposed filters, but upstream PR creation permissions issues have prevented formal submission.

What HN is Saying

The Hacker News thread is running hot. A few representative comments:

On quality:

"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."

"I don't understand how Codex can blunder so badly. I imagine that even if they would be using vibe-coding, surely they must have some good engineers."

On OpenAI's response:

"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."

"SQLite + unbounded TRACE logs = firehose in a bathtub. No rotation, no cap, no surprise. The RAISE(IGNORE) fix patches a design flaw. OpenAI's silence is worse than the bug."

Defending the nuance:

"This thread will become a typical 'haha slop company made slop' but I've been bitten by a bug exactly like this before in a (pre-AI, artisan) OSS project."

Fair point. Shipping trace logging to production is a classic blunder that predates AI coding tools by decades. The difference is the volume - modern SSDs are fast enough that the app remains usable while silently burning through drive endurance.

On AI tool quality generally:

"I want to like codex, but the quality is just not very good, especially when compared to Claude."

"OpenAI really snatched defeat from the jaws of victory late last year when Claude Code was a laggy mess. Nowadays Codex has typing latency out of the gate, whereas Claude Code has the odd pause but generally displays my key presses as... you know... I press them."

One commenter noted that Claude Code has similar logging behavior - "writes massive debug logs to ~/.claude/logs" - suggesting the problem may be broader than just Codex.

Workarounds

Until OpenAI ships a fix, you have options:

Option 1: Disable logging via SQLite trigger

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

This blocks new log inserts at the database level.

Option 2: Reclaim space with VACUUM

sqlite3 ~/.codex/logs_2.sqlite "VACUUM FULL;"

One user reported shrinking their log file from 27GB to 73MB with this command.

Option 3: Delete the log files

rm ~/.codex/logs_2.sqlite*

The files will be recreated, but you will have bought yourself time.

Option 4: Symlink to tmpfs

For users concerned about SSD wear, symlinking the logs directory to a RAM-backed tmpfs prevents disk writes entirely (at the cost of losing logs on reboot).

The Bigger Picture

This bug is a reminder that even flagship developer tools from major AI labs ship with basic quality issues. The actual bug - excessive logging - is mundane. The response - silence for over a week on a high-visibility issue - is more concerning.

For teams evaluating AI coding assistants, bugs happen. What matters is how vendors respond. A quick acknowledgment and ETA would have defused most of the frustration in the HN thread.

If you are using Codex in production, check your ~/.codex/ directory size and apply one of the workarounds above. Monitor your SSD health metrics if you have been running Codex for extended periods.

Sources

• GitHub Issue #28224
• Hacker News Discussion