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

Activity

1. wuaingxuagnxa

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 17, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Jun 17, 2026
3. wuaingxuagnxa commented on Jun 17, 2026

   

   wuaingxuagnxa

   on Jun 17, 2026

   Last edited by wuaingxuagnxa

   Author

   More actions

   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.
4. wangskyone commented on Jun 18, 2026

   

   wangskyone

   on Jun 18, 2026

   More actions

   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.
5. wuaingxuagnxa commented on Jun 18, 2026

   

   wuaingxuagnxa

   on Jun 18, 2026

   Author

   More actions

   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.
6. jpaodev commented on Jun 30, 2026

   

   jpaodev

   on Jun 30, 2026

   More actions

   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!
7. wgu9 commented on Jun 30, 2026

   

   wgu9

   on Jun 30, 2026

   More actions

   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.