Codex Desktop loses visible chat history when local state SQLite index is corrupted

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

• #27361
• #27340

Powered by Codex Action

Adding another macOS case with the same user-visible failure mode: local conversation history became inaccessible because the Codex state SQLite database was malformed.

Environment:

Codex Desktop: 26.608.12217 (CFBundleVersion 3722)
codex-cli: 0.138.0-alpha.7
Platform: macOS 26.5.1, build 25F80, arm64
Local state path: ~/.codex

User-visible error shown by Codex Desktop on launch:

Codex cannot access its local database.
The app cannot finish launching until its SQLite database is accessible.

Database path: Path unavailable in app-server startup error

Error: (code=1, signal=null).
Most recent error: Error: failed to initialize sqlite state runtime under /Users/<redacted>/.codex: failed to initialize state runtime at /Users/<redacted>/.codex: error returned from database: (code: 11) database disk image is malformed

What I found locally:

• The app could not launch until the local state DB problem was repaired.
• A saved corrupt backup of ~/.codex/state_5.sqlite was malformed.
• SQLite .recover was able to extract 24 thread rows from that malformed backup.
• The current repaired state_5.sqlite and logs_2.sqlite both pass integrity checks.
• session_index.jsonl and external_agent_session_imports.json referenced older imported sessions that were missing from state_5.sqlite.
• I found 16 external imported-session entries: 14 were recoverable because the source JSONL still existed and matched the recorded SHA256; 2 were skipped, one because the source file was missing and one because it contained no visible user/assistant content.
• After repair, the local DB has 42 threads total, including 14 restored claude-import threads, and PRAGMA integrity_check returns ok.
• A fresh export/recovery scan then converted 42 rollout JSONL files and reported missing_json: 0.

Impact:

This looked like conversation history loss to the user, and Codex Desktop was blocked from launching by the malformed SQLite state database. Recovery required manual database inspection, SQLite recovery, reconstructing missing thread rows, generating rollout JSONL files, and backing up/restoring state. That is too much for a normal user, especially because the conversations may contain important project context.

Suggested product behavior:

• On startup, run an integrity check for state_5.sqlite before failing the whole app launch.
• If the DB is malformed, preserve the corrupt DB/WAL/SHM files as a diagnostic backup and attempt an automatic rebuild from sessions/**/rollout-*.jsonl, archived_sessions, session_index.jsonl, and imported-session metadata.
• If automatic recovery is possible, show a clear UI message such as: “History index was repaired; your conversations were preserved.”
• If automatic recovery is not possible, show the exact DB path and a supported repair command instead of Database path: Path unavailable.
• Consider adding a supported command such as codex doctor --repair-history or an equivalent Desktop recovery flow.

No raw rollout content, full database files, logs, auth files, or private prompts are attached publicly. I can provide redacted diagnostic queries or recovery statistics if maintainers say which fields are useful and safe to share.

This is a clean index-versus-transcript case: SQLite reported database disk image is malformed, while rollout scanning had no errors and rebuilding the index restored history.

I’m testing Codex Rescue as a local-first diagnostic when the durable rollout survives but Codex’s state database does not. It will not repair or modify SQLite and leaves every source rollout untouched. The useful check is whether it can independently enumerate and classify the sessions before any index rebuild.

If you retained the pre-rebuild backup or encounter it again, could you run:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Please share sanitized output only—no databases, raw JSONL, prompts, local paths, account data, or secrets.

https://github.com/shleder/codex-rescue

Adding a recurrent macOS case with an archive failure as the user-visible symptom.

Environment

• Codex Desktop: 26.820.60940, build 7119
• macOS: 26.6.2, build 25G83, Apple Silicon
• Bundled codex-cli: 0.150.0-alpha.8
• Standalone codex-cli: 0.150.0
• ~/.codex is on an internal APFS SSD
• SMART status: verified
• Approximately 875 GB free

Recurrence

The previous state database became corrupt on August 20. I rebuilt Codex from scratch that evening. The replacement state_5.sqlite became corrupt again by August 26.

This has happened repeatedly despite several complete Codex resets, roughly once per week.

Current failure

Archive requests reach thread/archive, then fail with:

errorCode=-32603
failed to archive session: thread-store internal error:
failed to update archived thread metadata:
error returned from database: (code: 779)
database disk image is malformed

PRAGMA quick_check reports:

wrong # of entries in index idx_threads_archived_cwd_created_at_ms
wrong # of entries in index idx_threads_source
wrong # of entries in index idx_threads_created_at

codex doctor --json reports many missing entries across additional thread indexes.

logs_2.sqlite is also inconsistent:

Freelist: size is 0 but should be 4

The goals, memories, queue, and thread-history databases pass integrity checks.

Data and recovery validation

The rollout files remain present:

• 212 active rollout files
• 1 archived rollout file

I created read-only snapshots and tested repairs without modifying the active databases:

state_5.sqlite: REINDEX -> PRAGMA integrity_check = ok
logs_2.sqlite: VACUUM -> PRAGMA integrity_check = ok

The conversation records remain intact, and the current state corruption is repairable without rebuilding all Codex data.

Update timing

The first archive failure was logged at 2026-08-26T23:06:20Z.

The Sparkle updater did not begin installing the current update until 2026-08-26T23:06:31Z, so the corruption existed before that update started.

No database files or raw rollout content are attached because they contain private thread metadata.