Codex is wearing down your SSD. This bug still isn't fixed.

It writes to your disk non-stop in the background, even when you're idle. Setting RUST_LOG=warn doesn't stop it. CLI, Desktop, VSCode extension, all affected. The issue has been open since April 2026.

What I found on my machine

I checked today:

logs_2.sqlite      628 MB

Log level breakdown:

TRACE   78,350
INFO    51,467
DEBUG    9,256

TRACE dominates. inotify events, websocket packets, tokio internals. None of it useful to me. I barely used Codex over the holiday weekend. 628 MB anyway.

Why the file size lies

The logs_2.sqlite file size doesn't reflect actual disk writes.

SQLite uses WAL (Write-Ahead Log). New data hits the -wal file first, then gets merged back. Codex makes this worse: it inserts rows at full speed while pruning old ones. Row count stays flat. WAL keeps flushing to disk.

You stare at a few hundred MB and think you're fine. Your SSD's write endurance is draining. Community reports confirm significant write amplification during streaming sessions.

Check yours in 30 seconds

ls -lh "$HOME/.codex/logs_2.sqlite"*

sqlite3 "$HOME/.codex/logs_2.sqlite" \
  "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC;"

If TRACE dominates the count, or the -wal file has ballooned to gigabytes, you're hit.

The fix: a SQLite trigger that blocks all writes

I tried a few approaches. The cleanest one: add a BEFORE INSERT trigger to the logs table. Every insert gets silently ignored. One command, works permanently, doesn't break Codex.

Step 1: Quit Codex completely

CLI, Desktop, VSCode extension, any lingering processes. All of them. This matters.

Step 2: Install the trigger

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

Step 3: Verify

Confirm the trigger exists:

sqlite3 "$HOME/.codex/logs_2.sqlite" "SELECT name FROM sqlite_master WHERE type='trigger';"

You should see block_log_inserts.

Then test that it actually blocks writes:

sqlite3 "$HOME/.codex/logs_2.sqlite" \
  "INSERT INTO logs (ts, ts_nanos, level, target, estimated_bytes) VALUES (0, 0, 'TEST', 'check', 0); SELECT changes();"

Output should be 0. The insert got swallowed. Nothing hit disk.

Result

I ran both checks. Trigger installed, test insert returned 0. Reopened Codex, used it for the rest of the day. Everything works. Disk is quiet.

Reverting later

Once OpenAI ships a proper fix:

sqlite3 "$HOME/.codex/logs_2.sqlite" "DROP TRIGGER IF EXISTS block_log_inserts;"

Emergency option: delete the files

If Codex Desktop won't launch or your disk is full, you can nuke the log files. Quit Codex first (all processes):

rm "$HOME/.codex/logs_2.sqlite" "$HOME/.codex/logs_2.sqlite-wal" "$HOME/.codex/logs_2.sqlite-shm"

Codex rebuilds clean files on next launch. Space comes back immediately.

One gotcha: if a Codex process still holds the file handle, deleting won't free the space. Kill all Codex processes first. Reboot if you're unsure.

Things you should know

Your conversations live in state_5.sqlite. The logs_2.sqlite file only contains diagnostic logs. Deleting or blocking writes to it won't touch your chat history.

The trade-off with the trigger: you lose diagnostic logs if something goes wrong with Codex itself. Like disabling a dashcam. Fine for daily use. Revert it when OpenAI fixes the root cause.

The relevant issues are still open as of June 22, 2026.

References