OpenAI Codex Is Writing 640 TB a Year to Your SSD — Here's the Fix

In mid-June 2026, a developer noticed their SSD was taking on a strange amount of write traffic and traced it to OpenAI's Codex CLI. The agent was hammering a local SQLite database with diagnostic logs at the noisiest possible level. Over roughly 21 days of uptime, that single source had written about 37 TB to the drive — which annualizes to a headline-grabbing ~640 TB a year. The story was picked up by The Register, TechTimes, Notebookcheck and others, and tracked on GitHub as issue openai/codex#28224.

This post is the practical version: what the bug actually is, whether you were affected, how to read your SSD's lifetime write counter, how to stop the bleeding, and the honest status of the fix as of late June 2026. No drama about your drive instantly dying — just the numbers and the commands.

What is the Codex SSD bug?

Codex CLI keeps a local feedback/diagnostics log in a SQLite database at ~/.codex/logs_2.sqlite (plus its -wal and -shm companion files). The problem: that SQLite logging sink ran at a global TRACE level by default and did not respect the standard RUST_LOG environment variable. So even users who set RUST_LOG=warn still got every TRACE-level event persisted to disk.

TRACE is the firehose setting. The log captured things like raw WebSocket payload events streamed back from the model, mirrored telemetry records, and noisy events from bridged dependencies. During an active streaming response, observers reported sustained writes in the multi-MiB/s range to the SQLite WAL file. Most of that volume was low-value noise — the kind of data nobody needs retained on a durable, write-limited medium.

Because SQLite's write-ahead log gets continuously appended and checkpointed, the on-disk write amplification stacked up fast. Hence the eye-watering extrapolation in the issue title: ~640 TB/year.

How bad is 640 TB a year, really?

Worth being measured here. "640 TB/year" is an extrapolation from ~21 days of one heavy user's uptime, not a guaranteed figure for every install. Your actual numbers depend on how many hours a day Codex runs and how much streaming you do. A developer who fires up Codex for an hour a day will see a small fraction of that.

That said, the context matters because SSDs have a finite write budget, expressed as TBW (terabytes written) — the endurance the manufacturer warrants before the warranty lapses. Consumer NVMe drives commonly land somewhere in the low hundreds of TBW per terabyte of capacity (figures vary widely by model and capacity). So a sustained ~640 TB/year is genuinely meaningful against a drive rated for, say, 600 TBW.

The TBW ranges above are rough, capacity-dependent order-of-magnitude figures — check your specific drive's spec sheet for the real number. The takeaway isn't "your SSD is about to die." It's that an idle background logger should write near-zero, not contend for your drive's lifetime endurance. Reaching the rated TBW also doesn't mean instant failure; it's the warranty boundary, and drives often survive well past it. Still, burning endurance for nothing is the definition of a bug worth fixing.

Am I affected?

You were potentially exposed if all of these were true:

• You ran the Codex CLI (or the desktop/JetBrains variants that embed the same app-server) for meaningful stretches.
• You were on a build from before the 0.142.x fixes (released June 22, 2026).
• The file ~/.codex/logs_2.sqlite exists and has been growing.

Quick local sanity check — see how large the log database and its WAL have gotten:

ls -lh ~/.codex/logs_2.sqlite*

A large, actively-growing -wal file while Codex is mid-response is the tell. To know what it actually cost your drive, read the SSD's own lifetime write counter — covered next.

How do I check how much my SSD was written to?

Every SSD tracks its own cumulative "lifetime bytes written" in SMART data. Reading it tells you the drive's total writes since manufacture (not Codex-specific), but it's the ground truth for endurance used.

Linux

Install smartmontools, then read the NVMe health page:

# Debian/Ubuntu: sudo apt install smartmontools
# Fedora/RHEL:   sudo dnf install smartmontools

sudo smartctl -A /dev/nvme0

Look for the Data Units Written line. Modern smartctl prints a human-readable total in brackets, e.g. Data Units Written: 12,847,302 [6.57 TB] — the bracketed figure is your answer. If you ever need to compute it by hand, the NVMe spec defines a data unit as 1,000 × 512 bytes, so bytes = value × 1000 × 512.

For older SATA SSDs, the equivalent attribute is usually Total_LBAs_Written (multiply by the logical sector size, typically 512):

sudo smartctl -A /dev/sda | grep -i Total_LBAs_Written

macOS

macOS has no built-in SMART byte counter, but smartmontools works via Homebrew:

brew install smartmontools
sudo smartctl -A /dev/disk0   # read Data Units Written, same as Linux

Apple Silicon internal storage can be uncooperative with smartctl; if it returns nothing useful, a third-party tool that surfaces NVMe SMART data is the fallback.

Windows

The simplest path is CrystalDiskInfo, which displays "Total Host Writes" (or "Total NVMe Host Writes") directly in the GUI — no command line needed. smartctl for Windows works too if you prefer the terminal.

How do I fix the Codex SSD wear bug?

There are two layers: the real fix (update) and a pre-update stopgap (redirect the log off your SSD).

1. Update Codex — the actual fix

OpenAI merged three fixes into the Codex repo by June 23, 2026, which together — by the issue reporter's own measurement — cut roughly 85% of the log volume. Two of them shipped in the stable 0.142.0 line: PR #29432 (stop logging every Responses WebSocket event) and PR #29457 (filter noisy targets from the persistent log). Updating is the right move:

# npm
npm install -g @openai/codex@latest

# Homebrew (Codex ships as a cask)
brew upgrade --cask codex

# or, where supported, Codex can self-update
codex update

# confirm the version
codex --version

A third follow-up, PR #29599 (stop persisting bridged dependency log events), is slated for 0.143.0, which as of late June 2026 was still in alpha pre-release — so the last slice of noise lands once that release goes stable. The two stable fixes already handle the bulk of it. Run codex --version and check the releases page for the latest stable build before assuming you're fully patched.

2. Redirect the log to RAM (pre-update stopgap, Linux)

If you can't update immediately, point the log file at a RAM-backed filesystem so writes never touch the SSD. The log holds internal diagnostics, and on pre-fix builds those traces could include raw WebSocket/SSE payloads — so treat the file as potentially sensitive, but losing it on reboot is harmless.

Pick a target that's genuinely RAM-backed. On Linux, /dev/shm is tmpfs by default, which makes it a safer choice than /tmp (many distros put /tmp on the SSD). If you do want to use /tmp, confirm it first — this is the step most write-ups skip:

df -h /tmp        # only safe if the Filesystem column shows "tmpfs"

Redirect the file into a private tmpfs dir (quit Codex first so it isn't holding the database open):

# quit Codex, then:
mkdir -p "/dev/shm/codex-$(id -u)" && chmod 700 "/dev/shm/codex-$(id -u)"
rm -f ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm
ln -s "/dev/shm/codex-$(id -u)/logs_2.sqlite" ~/.codex/logs_2.sqlite

SQLite recreates the database and its WAL/SHM files through the symlink on next launch. The symlink in ~/.codex persists across reboots; only the RAM-backed target is wiped, and Codex simply recreates it. For multi-user boxes, the per-UID directory with chmod 700 keeps the log private rather than dropping a predictable file in shared /tmp.

macOS note: /tmp is NOT a RAM disk

On macOS, /tmp (and $TMPDIR) sit on the on-disk APFS volume, so symlinking there does not spare your SSD. On Apple Silicon Macs the internal SSD also isn't user-replaceable, which makes the update path even more clearly the right answer. If you genuinely want a RAM-backed redirect on macOS, you'd have to create an explicit RAM disk (via hdiutil/diskutil or a helper app) and point the log there — more friction than it's worth now that the fix has shipped. For Mac users, just update Codex.

Is the bug patched now?

Largely. The two fixes responsible for the bulk of the write volume are in the stable 0.142.x line (released June 22, 2026, with 0.142.2 following on June 25), and the upstream issue was closed on June 23 once all three PRs were merged. But the third PR (#29599) ships in 0.143.0, which was still in alpha pre-release as of late June 2026 — so a slice of the noise isn't in a stable build yet. Practical advice: update to the latest stable Codex now, then keep half an eye on ~/.codex/logs_2.sqlite and its WAL while Codex is running. If it's still growing fast for you, apply the RAM-redirect stopgap and watch for 0.143.0 going stable.

Frequently asked questions

Did the Codex bug permanently damage my SSD?

Almost certainly not on its own. SSD endurance (TBW) is a budget, not a cliff — reaching the rated number is the warranty boundary, not the moment of failure, and drives frequently outlive it. Read your drive's lifetime Data Units Written via smartctl or CrystalDiskInfo to see how much endurance was actually consumed; for most users running Codex part-time, it's a modest dent, not a death sentence.

What is in ~/.codex/logs_2.sqlite — can I just delete it?

It's an internal diagnostic/feedback log, not a record of your project files. On pre-fix builds, though, the TRACE traces could include raw WebSocket/SSE payloads, which may contain bits of conversation content — so don't casually upload or share the file. Deleting it after quitting Codex is safe (it just drops local diagnostics and is recreated on next launch), which is also why redirecting it to RAM is an acceptable stopgap.

Why didn't RUST_LOG=warn stop the writes?

The SQLite logging sink operated outside the standard RUST_LOG filter, so it persisted TRACE-level events regardless of what you set. That's exactly what the fixes addressed — narrowing what reaches the durable SQLite sink rather than relying on the env var.

Which Codex version fixes it?

Two of the three fixes shipped in the 0.142.x release line (June 22, 2026), removing roughly 85% of the excess logging. The third fix targets 0.143.0, which was still in alpha pre-release as of late June 2026. Run codex --version and check the releases page for the latest stable build.

Does this affect Claude Code, Cursor, or other agents?

This specific bug is Codex's TRACE-to-SQLite logging path; it doesn't mean other agents have the same flaw. If you're comparing tools, see our Claude Code vs OpenAI Codex breakdown. For Codex-specific issues beyond this one, the common agent errors and troubleshooting guide is a useful companion.

Is the symlink workaround safe on macOS?

It won't help on macOS the way it does on Linux, because /tmp there lives on the on-disk APFS volume rather than RAM. On Mac, update Codex instead of symlinking — or set up a real RAM disk if you insist on a redirect.

If your team runs coding agents day to day, this is a good reminder to keep an eye on what your tools write to disk and to update fast when a regression like this surfaces. Need extra senior engineering hands to ship and keep things stable? Hire vetted remote developers through Codersera and extend your team without the hiring overhead.