AI agent storage incident

Codex SQLite Feedback Logs Disk Writes

If Codex Desktop or CLI is writing heavily to logs_2.sqlite, logs_2.sqlite-wal, or feedback log tables, separate three problems before cleanup: retained database size, live WAL growth, and historical insert/prune write amplification. The safest first move is measurement, not deleting the whole Codex home.

What is happening

Codex stores diagnostic feedback logs in SQLite. A large logs_2.sqlite file is one symptom, but it is not the whole story. If rows are constantly inserted and pruned, retained row count may stay flat while the WAL, indexes, checkpoints, and filesystem write volume continue to grow. On a nearly full disk, a cleanup that rewrites the database can make the situation worse.

Read-only checks first

1. Measure file sizes for logs_2.sqlite, logs_2.sqlite-wal, and logs_2.sqlite-shm.
2. Check whether the WAL is visible growth or a deleted-open-inode problem.
3. Count retained rows and the current maximum row id without printing log bodies.
4. Sample row-id growth over 10-60 seconds to prove ongoing insert/prune churn.
5. Identify the writer process before moving or mutating the database.
6. Back up session state you care about before any destructive cleanup.

# macOS / Linux
db="$HOME/.codex/logs_2.sqlite"
du -sh "$HOME/.codex" "$db"* 2>/dev/null
lsof -nP "$db"* 2>/dev/null | head -40
sqlite3 "$db" 'select count(*) as retained_rows, max(id) as max_row_id from logs;' 2>/dev/null
sleep 15
sqlite3 "$db" 'select count(*) as retained_rows, max(id) as max_row_id from logs;' 2>/dev/null

# Windows PowerShell
$db = "$env:USERPROFILE\.codex\logs_2.sqlite"
Get-Item "$db*" | Select-Object Name,Length,LastWriteTimeUtc
sqlite3 $db "select count(*) as retained_rows, max(id) as max_row_id from logs;"
Start-Sleep -Seconds 15
sqlite3 $db "select count(*) as retained_rows, max(id) as max_row_id from logs;"

Safer cleanup order

1. Quit Codex Desktop and stop new CLI/TUI sessions before manipulating SQLite files.
2. If disk is critically low, move unrelated regenerable caches first instead of forcing SQLite to rewrite a huge file.
3. Checkpoint only after active readers/writers release the DB; then re-check file sizes and free space.
4. Avoid VACUUM until there is enough temporary headroom for a full rewrite.
5. If you use a temporary trigger or local patch, document the undo path and retest after Codex updates.
6. For the product fix, prefer lower default persisted log level, target filters, raw payload summaries, and a global size/write budget.

I would split this into three states before recommending cleanup:

1. Retained DB size: logs_2.sqlite is large because retained rows or free pages are large.
2. Live WAL growth: logs_2.sqlite-wal is still being written because Codex is actively inserting feedback rows.
3. Write amplification: retained row count is flat, but max(id) keeps climbing, so insert/prune/checkpoint churn is still producing disk writes.

Useful read-only checks:

- file sizes for logs_2.sqlite*
- retained row count and max(id)
- max(id) delta over 10-60 seconds
- active writer process
- lsof/open-file check before deleting or checkpointing

I would be careful with DELETE/VACUUM as a first recommendation on a nearly full disk: VACUUM rewrites the DB and may need temporary headroom. A safer workaround order is: stop Codex writers, measure, checkpoint if readers are gone, preserve session state, then decide whether to compact/move the log DB. The product fix should be a narrower persisted-log filter plus a global size/write budget, not user-side schema surgery.

Do Not Delete First

• Do not delete the whole ~/.codex folder if you care about sessions, auth state, or local configuration.
• Do not publish raw SQLite log rows; they may contain local paths, tool output, prompts, or response payloads.
• Do not run VACUUM on a huge database while the disk is already near full.
• Do not rely on retained row count alone; row-id churn and WAL writes can continue while retained rows stay flat.