Codex App fails to launch after update on macOS: state runtime sqlite (state_5.sqlite) "database disk image is malformed"

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #24006
• #23917
• #23247
• #22942
• #24001

Powered by Codex Action

Update — workaround confirmed. Renaming the corrupt state DB and relaunching gets the app back to a working state:

mv ~/.codex/state_5.sqlite ~/.codex/state_5.sqlite.bak

Then quit and reopen Codex. The app rebuilds a fresh state_5.sqlite on startup and launches normally.

Confirmed on my setup (Darwin 24.6.0 arm64, M4 Pro, macOS 15.7.3, Pro plan). App is fully usable again.

A few notes for anyone hitting this:

• Keep the .bak file for at least a session or two in case you discover missing state (project metadata, threads, etc.) and want to extract anything via sqlite3 state_5.sqlite.bak ".recover". In my case nothing important seemed lost after the rebuild, but YMMV.
• logs_2.sqlite (956 MB in my case) was untouched by this workaround and the app launches fine with it in place — so the corruption that wedges startup really is isolated to state_5.sqlite, not the oversized logs DB. That said, ~1 GB for a logs DB still looks like an unbounded-growth bug worth a separate look.
• This is exactly the auto-recovery behavior requested in #21750 — the app already does the right thing if state_5.sqlite is missing; it just doesn't handle the corrupt case. Detecting SQLITE_CORRUPT / database disk image is malformed at startup and quarantining the file (e.g. rename to state_5.sqlite.corrupt-<timestamp>) before reinitializing would resolve this entire class of post-update startup failures with no user intervention.

Hope this helps whoever lands here next while a proper fix is in flight.

For me it was the logs_2.sqlite that gave the crash. I renamed that one and it started working again

Proposed Solution: SQLite Corruption Auto-Recovery

Root Cause

StateRuntime::init_inner() handles missing databases (re-initializes) but does NOT handle corrupt databases — it hard-fails on any DB error including SQLITE_CORRUPT / "database disk image is malformed".

Fix

1. Auto-Recovery by Quarantine: Detect corrupt DB at startup, rename to .corrupt.{timestamp}.bak, re-initialize
2. Pre-Open Integrity Check: Run PRAGMA integrity_check before attempting to use the database
3. Bounded Log Growth: 50MB cap on logs_2.sqlite with periodic VACUUM
4. User-Facing Error Message: Clear recovery instructions instead of generic "cannot access database"

Key Code Change

// codex-rs/core/src/runtime.rs
fn recover_corrupt_db(db_path: &Path) -> Result<()> {
    let timestamp = Utc::now().format("%Y%m%d_%H%M%S");
    let backup_path = db_path.with_extension(format!("corrupt.{}.bak", timestamp));
    std::fs::rename(db_path, &backup_path)?;
    warn!("Quarantined corrupt database to {:?}", backup_path);
    Ok(())
}

Full solution: solutions/codex-24030-sqlite-corruption-auto-recovery-fix.md

It happens every time it autoupdates for me. Just discovered you can launch it from the command line, it'll prompt you to fix the database, then launch normally without loosing your data.

Workaround: reset Codex SQLite state

I ran into an issue where Codex could no longer open, and the root cause appeared to be related to its local SQLite state files.

The workaround that fixed it for me was:

1. Find all .sqlite files under any .codex directory.
2. Rename those .sqlite files to keep them as backups, for example:

file.sqlite -> file.sqlite.bak

1. Restart Codex and let it generate fresh SQLite database files automatically.

After doing this, Codex was able to start normally again.

Note that this may reset some local Codex state, but the original SQLite files are still preserved as .bak backups in case they are needed later.