# Codex Is Burning Through Your SSD. Here's How I Stopped It

> A practical guide to checking Codex's SQLite log writes, blocking the unwanted inserts, and protecting your SSD without deleting conversation history.

- Author: AI Kai
- Published: 2026-06-23
- Updated: 2026-08-23
- Topic: Codex
- Tags: codex, sqlite, ssd, disk-writes
- Canonical: https://hqman.me/blog/codex-ssd-disk-wear-fix/

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

```bash
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

```bash
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:

```bash
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:

```bash
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:

```bash
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):

```bash
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

- [openai/codex#28224](https://github.com/openai/codex/issues/28224) - root cause analysis, write amplification data
- [openai/codex#17320](https://github.com/openai/codex/issues/17320) - RUST_LOG bypass, TRACE ignores filter
- [openai/codex#22444](https://github.com/openai/codex/issues/22444) - deleted files don't free space (stale handles)