OpenAI Codex Was Quietly Destroying Your SSD - Here's How to Check and Fix It

Sometime around mid-June 2026, a GitHub issue with a brutal title started circulating on Hacker News: "Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance." Developer Rui Fan, a project management committee member of Apache Flink, had noticed his drive activity light blinking nonstop. He traced it to a SQLite file hiding in his home folder. After 21 days of normal uptime, his main SSD had absorbed 37 terabytes of writes all from OpenAI's Codex. Annualized: roughly 640 TB per year. A typical 1 TB consumer SSD is rated for about 600 TBW across its entire lifetime. One coding tool was consuming that warranty budget in under twelve months, silently, invisibly, with zero disk-space warnings of any kind.

The good news: Codex v0.142.0 shipped on June 23, 2026 with a fix that reduces write volume by approximately 85%. The bad news: the wear already absorbed by your drive cannot be reversed. If you have been running Codex for weeks or months on an older version, your SSD endurance counter has been quietly ticking down. This guide gives you everything you need to assess the damage, apply the patch, use the correct workaround if you cannot update yet, and clean up the bloated log file left behind.

• What Codex was writing and why standard disk-space tools couldn't detect it

• How to read SMART health counters on Linux, macOS, and Windows to see real write totals

• How to update to v0.142.0 the patched release that actually fixes the root cause

• Why the /tmp symlink workaround silently fails on macOS (and what to use instead)

• The SQLite trigger approach that blocks writes at the database level, cross-platform

• How to safely delete the bloated log file and go from gigabytes back to megabytes

The Bug That Hid in Plain Sight for Months

What makes this story particularly frustrating is how old the problem actually is. GitHub Issue #17320, titled "Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG," was filed on April 10, 2026 more than ten weeks before the June story broke. That issue documented write rates of approximately 5 MB/s during streaming, with peaks hitting 16 MB/s. It was acknowledged, a log rotation suggestion was offered, and the underlying cause was left untouched.

At least eight separate GitHub issues across the Codex repository documented different symptoms of the same root behavior throughout 2026: unbounded SQLite growth, indefinite WAL accumulation, severe disk I/O on Windows WSL2, memory churn from TRACE log pollution causing the Codex desktop app to become completely unusable on long sessions. None of these reports gained enough traction to force a fix. What finally worked was attaching a concrete, annualized TBW number to the issue something that made the severity impossible to dismiss and Hacker News picking it up.

The SQLite AUTOINCREMENT counter inside the database had surpassed 5.5 billion rows by the time Rui Fan measured it. The database file itself looked deceptively small. Codex prunes rows roughly as fast as it inserts them, keeping the on-disk file size calm. In one 15-second window captured in the issue, over 36,000 rows were inserted while the total retained row count held flat around 680,000. The file size metric the first thing every developer checks told you absolutely nothing about the physical write I/O happening underneath. This is why the bug survived undetected for so long.

Also worth knowing: the problem appears to trace back to February 2026, when app-server SQLite logs were configured to write at TRACE level. Notably, the code that introduced this behavior was reportedly reviewed by Codex itself a pointed reminder that AI code review is probabilistic, not guaranteed, and is no substitute for human oversight on decisions about production logging levels.

Why Codex Was Wrecking Your Drive - The Technical Cause

Two mechanisms working together made this bug so destructive: TRACE-level logging and SQLite WAL write amplification.

Codex's SQLite feedback sink was configured at global TRACE level by default the noisiest logging setting that exists. It captured everything without discrimination: raw WebSocket payloads from every streaming event, filesystem metadata lookups including mundane OS operations like opening /etc/passwd, /etc/ld.so.cache, and /etc/nsswitch.conf, every OpenTelemetry diagnostic event, and every inotify filesystem notification. Approximately 71% of logged data had no diagnostic value for the average user or even for OpenAI engineers debugging production issues. It was noise all the way down.

The second factor is how SQLite handles high-frequency writes. SQLite in WAL (write-ahead log) mode appends every change to a separate WAL file before checkpointing it into the main database file. When a process is inserting and deleting rows at the rate Codex was doing tens of thousands per minute the WAL file grows, gets checkpointed, grows again, gets checkpointed again. Every cycle means real physical writes to your NAND flash cells. The logical database size stays stable because Codex is pruning rows as fast as it inserts them. But your drive controller is absorbing every single WAL write and checkpoint write, far beyond what the file size implies. This is write amplification, and it is the reason the damage was completely invisible to standard tooling.

The third factor sealed it: Codex's SQLite logger ignored RUST_LOG entirely. Setting RUST_LOG=warn in your shell profile the standard Rust mechanism for controlling log verbosity had zero effect on the SQLite sink. It continued writing at full TRACE verbosity regardless of what you set. There was no documented, user-accessible way to quiet it before v0.142.0.

How Much Damage Has Already Been Done?

The honest answer is: it depends on how heavily you used Codex, on which version, and for how long. The 640 TB/year figure comes from a heavy-use scenario with Codex running persistently. Light users doing an hour or two of AI-assisted coding per session with Codex not running in the background saw significantly less. But even at 10% of the headline rate, you are looking at 64 TB/year still more than 10% of a mid-range drive's entire lifetime warranty consumed annually by a single logging file.

Common consumer SSD TBW ratings for context:

• Samsung 990 Pro 1 TB — 600 TBW

• WD Black SN850X 1 TB — 600 TBW

• Crucial P3 Plus 1 TB — 220 TBW

• Budget QLC drives — often 100–150 TBW

• Laptop soldered NVMe (thin-and-light) — frequently in the 100–360 TBW range

TBW ratings are not cliffs. Drives routinely exceed their warranty endurance, and manufacturers set these numbers conservatively. Your drive will likely keep working past its rated TBW. But it does mean endurance budget has been spent and on a soldered laptop SSD that cannot be swapped out, that budget is finite and non-recoverable. Checking your SMART counters now is the only way to know where you actually stand.

Step 1 — Read Your SSD's SMART Health Data Right Now

SMART (Self-Monitoring, Analysis and Reporting Technology) is the health reporting system built into every modern SSD. It tracks cumulative bytes written directly at the drive controller level, independent of which software caused them. Here is how to read it on each platform.

Linux

Install smartmontools if you don't have it, then query your drive:

sudo apt install smartmontools     # Debian / Ubuntu
sudo dnf install smartmontools     # Fedora / RHEL
sudo pacman -S smartmontools       # Arch / Manjaro

# NVMe drives (most modern machines):
sudo smartctl -A /dev/nvme0n1

# SATA SSDs:
sudo smartctl -A /dev/sda

On NVMe, look for Data Units Written. Multiply the value shown by 512,000 to convert to bytes, then divide by 1,000,000,000,000 to get terabytes. On SATA Samsung drives, look for attribute 233 (Media Wearout Indicator) 100 is new, lower values mean more wear used. Intel SATA drives show attribute 231 (SSD Life Left) with the same scale. To find which block device name to use, run lsblk first.

macOS

brew install smartmontools
sudo smartctl -A /dev/disk0

If you are on Apple Silicon, the internal SSD uses Apple's proprietary interface and may not expose standard SMART attributes through smartmontools. In that case, open System Information (hold Option, click the Apple menu, select System Information), navigate to NVMe, and look at the available health fields. Alternatively, DriveDx and similar paid utilities expose Apple SSD health data on Apple Silicon if you need the full picture.

Windows

Download CrystalDiskInfo — it is free, portable (no install required), and reads SMART data clearly. Open it and look for:

• Total Host Writes — cumulative data ever written to the drive in terabytes

• Health Status — Good (blue), Caution (yellow), Bad (red)

• Power On Hours — gives context for how long the drive has been running

If Health Status shows Caution, one or more SMART attributes have crossed a threshold the manufacturer considers a warning sign. It does not mean failure is imminent, but treat it seriously and monitor the drive closely. If Total Host Writes looks unusually high relative to your drive's TBW rating and how long you have owned it, Codex is a likely contributor.

Step 2 — Inspect the SQLite Log File Directly

Before applying any fix, check what state the Codex log file is currently in. Quit Codex completely first, then:

# Check current file sizes (main file + WAL + SHM sidecar files):
ls -lh ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm 2>/dev/null

# Check how many rows are currently retained:
sqlite3 ~/.codex/logs_2.sqlite "SELECT COUNT(*) FROM logs;" 2>/dev/null

# Check the AUTOINCREMENT counter — proxy for total historical writes ever made:
sqlite3 ~/.codex/logs_2.sqlite "SELECT MAX(rowid) FROM logs;" 2>/dev/null

The file size on disk will probably look surprisingly small typically a few hundred MB to a couple of GB because Codex has been pruning rows continuously. But if MAX(rowid) returns a number in the hundreds of millions or billions, you know enormous write I/O has occurred. The gap between the current row count and the MAX rowid tells the real story: one user reported a 10,000x gap, meaning 10,000 rows had been inserted and deleted for every 1 row currently retained. That is the write amplification made visible.

One community member went from a 27 GB log file down to 73 MB just by deleting it and letting Codex recreate a clean one. The file contains only diagnostic telemetry no conversation history, no project data, no API keys. Deleting it is completely safe.

Step 3 — Apply the Real Fix: Update to Codex v0.142.0+

This is the most important step. Three pull requests were merged to address the root cause:

• PR #29432 — stopped logging every Responses WebSocket event. Previously, each successful WebSocket event generated three separate SQLite records: a TRACE log, an OpenTelemetry log event, and an OpenTelemetry trace event. The partition budget for these rows filled instantly, triggering a continuous churn of insertions and deletions. After this fix, only essential performance data is retained.

• PR #29457 — filtered noisy targets from the SQLite sink. The sink had been persisting high-frequency dependency logs (inotify events, locale lookups, WebSocket internals) alongside mirrored OpenTelemetry events. This fix explicitly excludes the bridged log data.

• PR #29599 — additional filter for bridged dependency log events targeting v0.143.0, with an alpha tag already published June 24, 2026.

PRs #29432 and #29457 both shipped in v0.142.0. Together with PR #29599, the reporter's own measurements show approximately 85% reduction in write volume. SQLite logging is not disabled entirely complete removal would make future debugging harder but the TRACE-level noise that made up the vast majority of writes is gone.

# Update via npm:
npm install -g @openai/codex@latest

# Confirm the version:
codex --version
# Should show 0.142.0 or higher

Do this before applying any workaround. If you are already on v0.142.0+, the manual workarounds below are optional though cleaning up the old log file is still worth doing.

If You Cannot Update Yet — Two Workarounds

If you are stuck on an older version for any reason (locked corporate environment, compatibility constraint, active project with a pinned dependency), two workarounds exist. One of them has a critical limitation that the majority of articles about this bug got wrong.

The /tmp Symlink — Linux Only. Do NOT Use on macOS

The most widely shared workaround is symlinking ~/.codex/logs_2.sqlite to /tmp/, redirecting writes to a RAM-backed filesystem so nothing hits the SSD. This works correctly on Linux, where /tmp is typically a tmpfs filesystem mounted entirely in RAM.

Before applying it, verify that /tmp is actually RAM-backed on your machine a step most write-ups skipped entirely:

# Verify /tmp is tmpfs (RAM), not disk-backed:
mount | grep /tmp
# Should show: tmpfs on /tmp type tmpfs

# Alternative check:
df -T /tmp
# TYPE column should say: tmpfs

If the output shows tmpfs, you are clear to proceed:

# Quit Codex completely first, then:
rm -f ~/.codex/logs_2.sqlite
rm -f ~/.codex/logs_2.sqlite-wal
rm -f ~/.codex/logs_2.sqlite-shm
ln -s /tmp/codex_logs.sqlite ~/.codex/logs_2.sqlite

Writes now land in RAM. On reboot, the symlink target disappears and Codex creates a fresh database which is fine, since the file contains nothing you need to keep across reboots.

macOS users: do not use this workaround. On macOS, /tmp is a symlink to /private/tmp, which lives on your actual SSD not in RAM. Redirecting Codex's log file to /tmp on macOS just moves the writes to a different directory on the same physical drive. Multiple articles recommended this for macOS without flagging the limitation. It provides zero protection on Apple hardware. macOS users should use the SQLite trigger approach below.

The SQLite Trigger — Works on Linux, macOS, and Windows

This approach blocks new log inserts at the database engine level, regardless of what Codex tries to write above it:

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

The trigger tells SQLite to silently discard every INSERT before it executes. Codex continues running normally. No rows reach the disk. The only meaningful downside: if you need to submit a support feedback report to OpenAI with log data attached, the log file will be empty. For the overwhelming majority of developers, this is not a concern worth weighing against protecting their SSD.

On Windows, the path is typically %APPDATA%Codexlogs_2.sqlite. Install the sqlite3 command-line tool from sqlite.org, then run the equivalent command in PowerShell or Command Prompt, adjusting the path to match your system.

One caveat: if Codex detects a missing or corrupted database and recreates logs_2.sqlite on the next launch, the trigger will be gone. Verify it survived after restarting Codex:

sqlite3 ~/.codex/logs_2.sqlite ".schema"
# The trigger definition should appear in the output

If the trigger is missing, re-run the CREATE TRIGGER command.

Clean Up the Leftover Damage

Whether you have updated to v0.142.0 or applied a workaround, clean up the log files that accumulated before the fix. Do this with Codex fully quit:

# Delete the main log file and its WAL and SHM sidecar files:
rm -f ~/.codex/logs_2.sqlite
rm -f ~/.codex/logs_2.sqlite-wal
rm -f ~/.codex/logs_2.sqlite-shm

# Codex recreates a clean, minimal logs_2.sqlite on next launch automatically.

If you prefer to keep the file but compact it immediately rather than deleting it:

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

VACUUM rewrites the entire database file in compact form and releases freed pages back to the operating system. One developer in the GitHub thread went from a 27 GB file to 73 MB with this single command. After cleaning up, launch Codex and monitor your drive activity for a few minutes with iotop (Linux) or Activity Monitor's Disk tab (macOS) to confirm the runaway writes have stopped.

Should You Keep Using Codex After This?

Honestly, yes if you are on v0.142.0 or higher. The fix is real. An 85% reduction in write volume is a substantial improvement, and the third PR targeting v0.143.0 closes most of the remaining gap. OpenAI's engineers moved quickly once the issue had enough visibility, merging three fixes within days of the Hacker News thread gaining traction.

What this incident does genuinely change is how you should think about AI coding tools running persistently on your machine. I used to treat CLI tools the way I treated curl or grep run it, it does the thing, it exits, done. Codex, Claude Code, and similar local agents are different. They maintain SQLite databases, stream telemetry, watch filesystems, and keep processes alive across your entire working session. They are closer in behavior to a database daemon or a monitoring agent than to a traditional command-line utility. They deserve the same operational attention you would give any long-running process.

I now run sudo smartctl -A /dev/nvme0n1 once a month on my development machine. It takes five seconds. After this incident, that habit feels less like paranoia and more like basic hygiene. If you had been checking your SMART counters through April and May 2026, the anomalous write rate would have been visible weeks before the story broke publicly.

If you are evaluating alternatives or want a broader picture of how these tools compare in architecture and local resource footprint, our Claude Code vs Cursor vs GitHub Copilot comparison for 2026 covers the landscape in detail. It is also worth noting that at least one developer on the GitHub thread flagged similar logging behavior in Claude Code at ~/.claude/logs though the scale and configuration appear different. The pattern of local agents accumulating logs and telemetry is broader than just Codex.

What This Tells Us About AI Coding Tools in General

Shipping a TRACE-level logger into a production tool writing to a persistent local database, bypassing standard log-level controls, with no user-accessible way to quiet it is a software mistake that long predates AI coding assistants. What makes this case different is scale. Modern SSDs are fast enough that an application can sustain enormous write throughput while remaining perfectly usable, making the damage easy to miss until significant wear has accumulated. And modern AI tools are persistent enough always running, always watching, always streaming to exploit that throughput continuously.

As AI coding assistants become more central to developer workflows, their operational footprint on consumer hardware becomes as important as their token consumption on cloud infrastructure. We carefully track LLM API costs our LLM API cost calculator helps with that but local SSD endurance has largely been invisible until now. After this incident, it probably will not stay invisible for long. Watch for similar issues in any AI agent tool you run persistently.

If you are new to AI-assisted development and want to understand how the vibe coding ecosystem fits together and what resource overhead each approach carries our vibe coding guide for 2026 gives a comprehensive overview. And if you have run into other AI IDE performance issues, our Cursor agent stuck and slow loading fix guide addresses similar patterns in another major AI coding tool. Resource monitoring across AI tools is a skill worth building now, before the next incident.

All tools on WebToolsHub are 100% client-side they run entirely in your browser, write nothing to your disk, and send no data to any server. That design principle feels especially relevant after a week like this one.

Frequently Asked Questions

Which version of Codex has the SSD bug fixed?

Codex v0.142.0, released June 23, 2026, includes two of three merged fixes (PR #29432 and PR #29457) that reduce write volume by approximately 85%. A third fix (PR #29599) targets v0.143.0, with an alpha tag already published June 24, 2026. Update with npm install -g @openai/codex@latest and verify with codex --version. If you are on 0.142.0 or higher, the major write reduction is already in place.

How do I check how much my SSD has been affected?

Read your drive's SMART health data. On Linux, install smartmontools and run sudo smartctl -A /dev/nvme0n1 for NVMe drives. On Windows, use the free tool CrystalDiskInfo and look at Total Host Writes and Health Status. On Intel Mac, smartmontools works via Homebrew. On Apple Silicon, use System Information or a dedicated tool like DriveDx. Compare Total Host Writes against your drive's published TBW rating to understand how much of the warranty endurance has been consumed.

Why did the /tmp symlink workaround not work on my Mac?

Because on macOS, /tmp is not RAM-backed. It is a symlink to /private/tmp, which lives on your SSD. Redirecting Codex's log file to /tmp on macOS just moves the writes to a different folder on the same physical drive it does not protect your SSD at all. Most articles reporting this workaround did not flag this distinction. Mac users should use the SQLite trigger instead: sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

Is it safe to delete ~/.codex/logs_2.sqlite?

Yes, completely safe. The file contains only diagnostic telemetry logs no conversation history, no project data, no authentication tokens, nothing you would want to preserve. Codex automatically creates a fresh, minimal database on next launch. Make sure Codex is fully quit before deleting. Also remove the WAL and SHM sidecar files: ~/.codex/logs_2.sqlite-wal and ~/.codex/logs_2.sqlite-shm. One developer went from 27 GB to 73 MB just by doing this.

Why did setting RUST_LOG=warn not stop the excessive logging?

Codex's SQLite feedback sink was coded to bypass RUST_LOG entirely. The standard Rust mechanism for controlling log verbosity setting RUST_LOG=warn or any other level in your shell environment had no effect on the SQLite logger. It continued writing at full TRACE verbosity regardless of what you set. This was documented as a separate bug as early as April 10, 2026 in GitHub Issue #17320, but was not treated as part of the same root problem until Rui Fan's June 14 report attached concrete TBW numbers. The v0.142.0 fixes address the root cause by stopping specific event categories from being written to SQLite at all, rather than honoring RUST_LOG.

Could other AI coding tools have similar logging problems?

Possibly. At least one developer in the GitHub thread noted that Claude Code maintains debug logs at ~/.claude/logs with behavior worth monitoring. The general pattern local AI agents that maintain persistent state, telemetry databases, and session logs creates structural conditions for over-aggressive logging in early versions. The appropriate response is not to avoid these tools but to monitor their local footprint. SMART health monitoring with smartmontools is the most reliable way to catch runaway disk writes regardless of which tool causes them. Check it monthly as a baseline habit.

Has OpenAI issued a statement or offered compensation for SSD damage?

As of June 25, 2026, OpenAI has not issued a formal public statement about the bug and no compensation program has been announced. OpenAI confirmed a fix was in progress through merged pull requests and one researcher publicly urged users to upgrade immediately, but there has been no formal acknowledgment of the potential SSD damage cost to users. Some estimates put the collective wear across all affected users in the "low-single-digit millions" of dollars, though this is speculative. If your drive has entered a Caution health state and you believe Codex contributed, contacting OpenAI support with your SMART data is an option, though there is no established process for hardware compensation at this time.

Does v0.142.0 completely fix the issue, or are writes still high?

v0.142.0 is a major improvement but not a complete elimination of SQLite logging. The two merged PRs cut approximately 85% of previous write volume by stopping WebSocket event logging and filtering high-frequency dependency logs from the SQLite sink. The third PR (targeting v0.143.0) handles remaining bridged log events. SQLite logging is not disabled entirely, because retaining some diagnostic data helps OpenAI engineers troubleshoot real bugs. After updating to v0.142.0, monitor your drive activity for a few days with iotop on Linux or Activity Monitor on macOS. If writes look normal for your usage pattern, the fix is working as intended for your workflow.