error returnedfrom database: (code: 5) database is locked

Neither Retry nor Back Up and Rebuild fixed the issue.
I also tried using a new Codex home directory inside WSL, but the issue still persists.

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.

### 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 3. 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.

I have already tried this approach, but the issue still persists. I even set up a new CODEX_HOME directory and let Codex regenerate the required files from scratch, but it still reports the same error.

> ### 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 > 3. 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. I have already tried this approach, but the issue still persists. I even set up a new CODEX_HOME directory and let Codex regenerate the required files from scratch, but it still reports the same error.

This workaround is not an option and based on my experience causing more trouble than help

coder@coder:~/codeprojects$ codex
Codex couldn't start because another Codex process is using its local data.
Quit any other copies of Codex that may still be running, then try again.
Technical details:
  Location: /home/coder/.codex/state_5.sqlite
  Cause: failed to initialize state runtime at /home/coder/.codex: failed to migrate state DB at /home/coder/.codex/state_5.sqlite: error returned from database: (code: 5) database is locked: error returned from database: (code: 5) database is locked: (code: 5) database is locked
ERROR: failed to initialize sqlite local db at /home/coder/.codex/state_5.sqlite: failed to initialize state runtime at /home/coder/.codex: failed to migrate state DB at /home/coder/.codex/state_5.sqlite: error returned from database: (code: 5) database is locked: error returned from database: (code: 5) database is locked: (code: 5) database is locked

Also getting this issue on Linux and this issue is really annoying. Trying multiple times to start codex helps, so technically it can be dealt with, so that's why I recommend to now mess around with the .sqlite files. Note that I usually have multiple Codex sessions running at the same time!

Source trace from current main that may explain why this is recoverable by retrying but still surfaces as a hard startup failure:

• Runtime startup opens multiple SQLite DBs through codex-rs/state/src/runtime.rs (state, logs, goals, memories specs).
• base_sqlite_options enables WAL and sets busy_timeout(Duration::from_secs(5)).
• open_sqlite opens the pool, then runs migrations immediately. If migration fails, it closes the pool and returns RuntimeDbInitError with the phase label (open or migrate).
• Lock classification is string-based in codex-rs/state/src/runtime/recovery.rs: "database is locked" / "database is busy".
• The CLI guidance in codex-rs/cli/src/state_db_recovery.rs prints the generic "another Codex process is using its local data" message for any classified lock.

The Linux report above looks specifically like a migration-phase lock:

failed to migrate state DB ... (code: 5) database is locked

That makes this different from corruption, and also different from a permanently bad sqlite file. Renaming/rebuilding sqlite files is unlikely to help if another process or concurrent startup immediately hits the same migration lock again; the user's observation that retrying startup sometimes works is consistent with transient contention.

Possible bounded fix:

• Treat migration/open SQLITE_BUSY separately from corruption in startup UX and recovery.
• Add a short retry/backoff around the migration phase, especially for state_5.sqlite, instead of failing after the sqlite busy timeout once.
• Include the DB label and phase (state DB, migrate) in the user-facing locked guidance, so users do not get routed toward destructive state-reset workarounds for a contention problem.
• Add a concurrency regression that starts two StateRuntime::init calls against the same fresh CODEX_HOME and verifies one does not leave the other in a permanent startup-failed state.