AgentFixFind a fix
CodexConfirmed workaroundUpdated Aug 20, 2026

Codex Desktop SQLite pool times out during startup

Recover Codex Desktop when logs_2.sqlite grows large and startup fails with pool timed out while waiting for an open connection.

Exact error

Match the message before using the fix

Codex cannot access its local databasepool timed out while waiting for an open connectionfailed to initialize sqlite state runtime

Quick answer

Start here

Back up the Codex data directory and fully stop Codex Desktop and its app-server. If `logs_2.sqlite` and its WAL are the large outliers, move only `logs_2.sqlite`, `logs_2.sqlite-wal`, and `logs_2.sqlite-shm` into a backup folder, leaving state, sessions, config, auth, goals, and memories untouched. The source report confirmed that Codex recreated a small healthy logs database and launched normally. Do not delete the whole `.codex` directory.

Diagnosis

Why it happens

  • Codex initializes state, logs, goals, and memories databases during app-server startup.
  • A multi-gigabyte diagnostic logs database or WAL on `/mnt/c` can make startup maintenance exceed the pool or Desktop handshake deadline.
  • The outer message says SQLite state runtime even when the conversation state database is healthy, so broad deletion risks unrelated data.

Safest first

Fixes, in order

01

Identify the diagnostic log database as the outlier

Applies when: When startup logs name the SQLite pool timeout and Codex Desktop never opens

The confirmed report found `logs_2.sqlite` and its WAL were several gigabytes while the actual state database remained healthy.

  1. Keep Codex closed and locate the active Codex data directory named in the startup log.
  2. Record the sizes of `logs_2.sqlite*`, `state_5.sqlite`, goals, and memories databases.
  3. Proceed only if the diagnostic logs are the clear outliers and the error matches the pool-timeout signature.
  4. Create a backup folder outside the active `.codex` directory.

Expected: The evidence points to the diagnostic log database rather than an indiscriminate failure of all Codex state.

02

Move only logs_2.sqlite and its sidecar files

Applies when: The exact large-log startup failure after a complete Codex shutdown

Moving is reversible and preserves the original files for rollback or diagnosis.

  1. Exit Codex Desktop and confirm no Codex app-server process is still using the files.
  2. Move `logs_2.sqlite`, `logs_2.sqlite-wal`, and `logs_2.sqlite-shm` to the backup folder.
  3. Leave `state_5.sqlite`, sessions, goals, memories, config, auth, and plugin data in place.
  4. Start Codex Desktop once and wait for the app-server handshake.

Expected: Codex recreates a small `logs_2.sqlite` and completes startup without losing existing threads or configuration.

03

Keep the backup until state and sessions are verified

Applies when: After Desktop launches successfully

The moved files are diagnostic logs, but retaining them briefly preserves a rollback and evidence trail.

  1. Open several existing conversations and verify normal state.
  2. Confirm goals, memories, configuration, and authentication still load.
  3. Record the new logs database size and startup time.
  4. Keep the backup until you are satisfied no unrelated data was moved.

Expected: Normal Codex state is intact and only the diagnostic log store was regenerated.

Verification

Prove the fix worked

  1. Codex Desktop passes the app-server initialize handshake.
  2. A fresh small `logs_2.sqlite` appears in the active data directory.
  3. Existing threads, sessions, goals, memories, config, and authentication remain available.

Escalation

If it still fails

  • Restore the moved files only while Codex is fully stopped if you need to roll back.
  • Do not delete or rename `state_5.sqlite`, the sessions directories, config, or auth files for this diagnosis.
  • Capture the exact database path, file sizes, Windows/WSL mode, and full app-server startup error for the upstream issue.

Scope

Environment and version notes

  • The confirmed report used Codex Desktop Windows Store 26.609 with bundled CLI 0.140 alpha and app-server in WSL.
  • The upstream issue remained open on August 20, 2026; the targeted file move is a reporter-confirmed recovery, not a shipped automatic fix.
  • Sources rechecked August 20, 2026.

Evidence

Sources

Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.