Codex CLI Eating Your SSD? Here's How to Check and Fix It (2026)

Originally published on the WebToolsHub blog.

Two weeks ago I almost paid for a battery replacement I didn't need. My laptop's fan ran nonstop, the SSD activity light blinked like a strobe, and Activity Monitor kept blaming a process I trust every day: codex. It turned out my hardware was fine. My SSD, on the other hand, had quietly absorbed terabytes of writes from a logging bug buried inside Codex CLI — and if you've been running OpenAI's terminal coding agent for more than a few weeks without updating it, there's a real chance yours has too.

This isn't a rumor or a worst-case edge case. It's a documented, measured bug that's been sitting in Codex CLI since at least April 2026, and it can write more data to your SSD in a single year than most consumer drives are rated to survive in their entire lifetime. There's a real fix, a real workaround, and a five-minute way to check whether your drive has already taken damage. Let's get into it.

If you're in a hurry, here's the short version:

• Codex CLI's local logging system has been writing up to roughly 640 TB per year to a single SQLite file — way past what a typical 1 TB consumer SSD is rated for.
• OpenAI shipped a real fix in Codex CLI v0.142.0 (already included in the current v0.142.2 release) that cuts this by about 85%.
• You can check exactly how much your drive has already absorbed, using tools you probably already have installed.
• The "symlink the log file to /tmp" workaround that's spreading around doesn't actually protect your SSD on macOS by default — and almost nobody mentions that part.

What's Actually Going Wrong Inside Codex CLI

Codex CLI keeps a local diagnostic log in a SQLite database at ~/.codex/logs_2.sqlite, along with its companion -wal and -shm files. That part is normal — most CLI tools log somewhere. The problem is the logging level it ships with: a global TRACE-level default that records everything, including raw WebSocket and SSE payloads, internal dependency chatter from libraries like tokio-tungstenite, and duplicated OpenTelemetry mirror events. Almost none of that is useful to you as a developer, and almost none of it survives more than a few seconds before the database prunes it. But the inserts and deletes keep happening, over and over, every single second Codex is running.

A developer going by 1996fanrui first quantified this in detail on June 14, 2026, in GitHub issue #28224. After noticing unusually high disk activity, they traced it back to Codex's SQLite log and measured roughly 37 TB written to their main drive over 21 days of uptime. Extrapolate that across a year and you land at roughly 640 TB — about 640 full-drive rewrites on a 1 TB SSD. It wasn't even the first report. An earlier issue, #17320, had flagged the same pattern back on April 10, 2026, clocking sustained writes around 5 MiB/s during normal streaming, spiking to 16 MiB/s. OpenAI just hadn't connected the dots yet.

Here's the part that makes this sneaky: the database file's logical size barely moves, because rows get pruned almost as fast as they're inserted. If you're just glancing at file size in Finder or File Explorer, everything looks fine. The actual physical writes hitting your NAND flash tell a very different story — which is exactly why the next section matters more than a quick glance at "Properties."

Just How Bad Is 640 TB a Year, Really?

Most consumer SSDs carry an endurance rating called TBW (Total Bytes Written) that tells you roughly how much data you can write before the drive's warranty — and reliability — starts running out. A typical 1 TB consumer NVMe drive is usually rated around 600 TBW. Compare that to what this bug can produce over twelve months:

Drive size	Typical consumer TBW rating	Time to exhaust at 640 TB/year
500 GB	~300 TBW	~5.5 months
1 TB	~600 TBW	~11 months
2 TB	~1,200 TBW	~22 months

Going past a TBW rating doesn't make a drive explode the next second — it's a warranty threshold, not a cliff edge. But write endurance on NAND flash is a real, physical, finite resource. The further past it you go, the more your odds of bad blocks, silent corruption, and eventual outright failure climb. None of that shows up as a friendly warning in your file manager. It usually shows up as a drive that "just died" one day, with no obvious cause — unless you'd been watching the right number all along.

Step 1: Check How Much Damage Codex Has Already Done

Before you touch anything else, get a baseline. You want your drive's lifetime total host writes, not its free space — those are two completely different numbers, and only one of them tells you the truth here.

On Linux (NVMe drives)

Install smartmontools if you don't already have it, then run:

sudo smartctl -a /dev/nvme0 | grep "Data Units Written"

Recent versions of smartctl already convert this to a human-readable figure in brackets, like Data Units Written: 7,861,234 [4.02 TB] — no manual math needed.

On Linux or older SATA SSDs

sudo smartctl -A /dev/sda | grep Total_LBAs_Written

Take the raw value, multiply by 512 (bytes per sector), then divide by 1,000,000,000,000 to get terabytes.

On macOS (Apple Silicon or Intel)

brew install smartmontools
sudo smartctl -a /dev/disk0 | grep "Data Units"

This works for your internal drive. It won't work for an external SSD plugged in over USB — macOS doesn't support NVMe SMART data over USB at all, regardless of which tool you try.

On Windows

Download CrystalDiskInfo, open it, and look at the Host Writes figure for your drive. It's already shown in GB or TB, so there's nothing to convert.

Once you have a baseline number, leave Codex running your normal workload for an hour, then check again. If the delta is measured in gigabytes for a single hour, the bug is actively chewing through your drive right now — and the next two sections are for you.

Step 2: Update Codex CLI — This Is the Actual Fix

Workarounds buy you time. Updating is the only thing that fixes the root cause. OpenAI engineer jif-oai merged two pull requests — #29432 (stopped logging every Responses WebSocket event) and #29457 (filtered out noisy persistent-log targets) — and both shipped in Codex CLI v0.142.0. The original reporter re-measured their own setup afterward and reported roughly an 85% drop in log volume. A third fix (#29599, stopping persisted "bridged" log events) is merged into main and targeting v0.143.0, which had an alpha build out as of June 24, 2026.

Check your current version, then update:

codex --version
codex update

If you installed via npm or Homebrew instead, update through that same channel rather than mixing methods:

npm install -g @openai/codex@latest
# or
brew upgrade --cask codex

As of this writing, the current stable release is v0.142.2, which already includes both merged fixes. If codex --version shows anything older than 0.142.0, you're still running the unpatched logging behavior — update before doing anything else on this list.

Step 3: The tmpfs Workaround — and the macOS Catch Almost Nobody Mentions

Updating handles new writes going forward. If you want to eliminate disk writes from this logging path entirely — say, while you confirm the update actually helped, or if you're stuck on an older version for some reason — the community workaround is to redirect logs_2.sqlite to a memory-backed filesystem instead of your physical disk.

On Linux, that's usually /tmp, because many distributions mount it as tmpfs — a filesystem backed by RAM, not flash. Here's the part that gets glossed over in almost every other write-up of this bug: you have to verify that before you rely on it. Run this first:

mount | grep " on /tmp "

If the output mentions tmpfs, you're genuinely protected — writes there never touch your SSD. If it shows ext4, xfs, or apfs, /tmp on your system is just another folder sitting on the exact disk you're trying to protect, and the symlink trick accomplishes nothing at all.

And here's the detail that matters most for Mac users specifically: on macOS, /tmp is not tmpfs by default. It's a symlink to /private/tmp, which lives on the same APFS volume as the rest of your disk. Apple has never shipped a Linux-style tmpfs for general use — the closest equivalent requires manually building a RAM disk with hdiutil, which is more setup than most people want for a temporary workaround.

If your check confirms tmpfs, the actual workaround is simple:

# 1. Quit Codex completely first
pkill -f codex

# 2. Back up and redirect the log file
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
ln -s /tmp/codex-logs-2.sqlite ~/.codex/logs_2.sqlite

The file holds internal diagnostic logs only, never your actual conversation history or code — so losing it on reboot costs you nothing. If your check came back negative, skip straight to Step 2 above and lean on the trigger-based block in the next section instead, since that works regardless of which filesystem you're on.

Windows users are in a tougher spot here: there's no built-in tmpfs equivalent, and no community-documented symlink workaround exists for Windows the way it does for Linux and macOS. If you're on Windows, updating to v0.142.0+ and using the trigger-block method below are your realistic options.

Bonus Cleanup: Shrinking a Log File That's Already Bloated

If you've been running an old Codex version for a while, your existing logs_2.sqlite file might already be several gigabytes, even though SQLite prunes old rows constantly. That's write amplification from the WAL (write-ahead log) — every insert and delete still has to be journaled before it gets checkpointed into the main file. The SQLite WAL documentation covers exactly why this happens if you want the full mechanics.

Quit Codex first, then run:

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

One developer in the GitHub thread reported this shrinking their file from 27 GB down to 73 MB — a genuinely dramatic recovery, and proof of just how much bloat had accumulated underneath a deceptively small "logical" footprint.

If you'd rather stop new log inserts altogether — useful if you don't care about Codex's internal diagnostics and just want the writes gone — there's also a database-level trigger that blocks inserts outright:

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

I'd treat this one as a last resort, not a default. It silently swallows inserts without erroring, which means it'll also swallow any genuinely useful diagnostic data if you ever need to report a different bug to OpenAI. Use it if you're stuck on a platform where neither the update nor the tmpfs trick is fully available to you yet — otherwise, updating is the cleaner long-term answer.

Is This a Codex-Only Problem, or Should You Worry About Other AI Coding Tools Too?

Good question, and an honest one to ask before assuming Codex is uniquely bad here. At least eight separate GitHub issues across the Codex repository document variations of this same logging pattern, across both the CLI and the desktop app — so it's clearly systemic to Codex's architecture, not a one-off fluke from a single build. One commenter on the thread also mentioned noticing unusually large debug logs from other terminal-based coding agents, which hints this might be a blind spot across the category rather than something unique to OpenAI. That specific claim hasn't been independently measured the way the Codex numbers have, so I won't treat it as confirmed — but it's a reasonable thing to keep an eye on regardless of which agent you run.

If you've hit other rough edges with AI coding tools recently, you're not imagining it — agentic CLIs are still young software, and growing pains like this show up across the board. There's a broader lesson buried in here too: local AI agents behave less like one-off scripts these days and more like long-running background services. They stay open for hours, stream constantly, and write to disk while you're doing something else entirely. That deserves the same scrutiny — log rotation, retention limits, visible resource usage — that we'd expect from any other service running continuously on our machines.

Quick Reference: Your Codex SSD Checklist

• Run codex --version and confirm you're on v0.142.0 or later (current stable: v0.142.2).
• If you're behind, run codex update immediately — this alone removes most of the problem.
• Baseline your SSD's total writes using smartctl or CrystalDiskInfo before and after an hour of normal Codex use.
• If logs_2.sqlite is several GB or more, quit Codex and run VACUUM; on it.
• Only use the tmpfs symlink trick after confirming /tmp is actually tmpfs on your system — especially on macOS.
• Set a recurring reminder to recheck your drive's write totals monthly while this is still a fresh fix.

Final Thoughts

I'll be honest about where this stands: as of late June 2026, OpenAI has shipped a real fix, but the underlying GitHub issue is still technically marked open even though the reporter says the merged PRs solved most of it. That's the nature of a live, still-unfolding incident, and it might look slightly different by the time you're reading this. What won't change is the underlying habit worth keeping: check your drive's actual write totals every so often, the same way you'd check disk space — because by the time an SSD fails outright, the warning signs were almost always there, just not in the place you were looking.

If this caught a problem before it got expensive for you, drop your codex --version output and your TBW numbers in the comments — I'm curious how widespread the actual damage turns out to be across different setups.

FAQ

What exactly is the Codex CLI SSD bug?
It's a logging bug where Codex CLI's local SQLite diagnostic log was configured to record everything at TRACE level by default, including low-value internal events and raw network payloads. The constant insert-and-prune cycle this creates can write up to roughly 640 TB per year to your drive, even though the database's visible file size barely changes.

How do I know if my SSD has already been damaged?
Check your drive's lifetime total host writes using smartctl on Linux or macOS, or CrystalDiskInfo on Windows, and compare that against your drive's rated TBW endurance, usually listed on the manufacturer's spec page. If your total writes are approaching or past that number, the drive has absorbed real wear, even if it's still working fine today.

Which version of Codex CLI fixes the SSD writes bug?
The first two fixes landed in v0.142.0 and are included in the current stable release, v0.142.2. A third fix is merged into main and targeting v0.143.0. Run codex --version to check yours, and codex update to get current.

Does updating Codex delete my existing oversized log file?
No. Updating stops the excessive logging going forward, but an existing bloated logs_2.sqlite file stays exactly as large as it was. Run sqlite3 ~/.codex/logs_2.sqlite "VACUUM;" after quitting Codex to reclaim that space.

Is the /tmp symlink workaround actually safe to use?
It's safe in the sense that the file only contains internal diagnostic logs, never your code or conversation history, so losing it on reboot costs you nothing. But it only protects your SSD if /tmp is mounted as tmpfs on your system — check with mount | grep " on /tmp " first, especially on macOS, where /tmp is disk-backed by default.

Does this bug affect Windows users too?
Yes — the underlying logging behavior is the same across Linux, macOS, and Windows, including under WSL2. Windows users don't currently have a documented tmpfs-style symlink workaround, so updating to v0.142.0 or later and using the SQL trigger-block method are the more realistic options.

Will this void my SSD's warranty?
Most manufacturer warranties are tied to a TBW threshold, not just time elapsed. If this bug pushed your drive's total writes past its rated TBW before you noticed, that portion of the warranty coverage may already be technically exhausted — worth checking your specific manufacturer's terms rather than assuming either way.

Can I keep using Codex CLI while I sort this out?
Yes. Updating to the current version is the single highest-impact step, and it takes under a minute. You don't need to stop using Codex entirely — you need to update it, then optionally apply the tmpfs or trigger-block workaround on top of the official fix.