on mac after codex update： Codex cannot access its local database.

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

• #23917
• #23247

Powered by Codex Action

Same Issue a simple reinstall does not fix it. Anyone have a fix ?

Same issue here... I tried renaming logs_2.sqlite like people said in the other tickets, but no luck. I can't start de app anymore.

Same issue here too

I got the same issue today, did anyone fix it?

Renaming state_5.sqlite had the effect.

You can fix it by

``mv ~/.codex/state_5.sqlite ~/.codex/state_2.sqlite``

You can use codex cli to start it again, codex cli will automatically fix this problem

Same issue here after an update. Renaming worked.

You can use codex cli to start it again, codex cli will automatically fix this problem

I did not have the ~/.codex/state_*.sqlite files present, so that does not work.

But @inRush's solution worked for me. Thank you!

System: macOS 26.5 arm64

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.

i asked Codex Cli to fix it :

What fixed it was not just renaming the .sqlite files. The missing piece was that Codex’s recovery flow expected this
directory to exist:

~/.codex/db-backups

In your case it did not exist, so “Back Up and Rebuild” failed with:

Recovery failed: ENOENT: no such file or directory, mkdir 'db-backups'

Here’s the exact summary you can post:

I was able to fix this by manually creating Codex’s missing backup directory and moving the active SQLite database
files out of the way.

The error dialog said Codex could not access its local SQLite database, and the recovery step failed with:

Recovery failed: ENOENT: no such file or directory, mkdir 'db-backups'

What worked:

```sh
mkdir -p ~/.codex/db-backups/manual-backup

find ~/.codex ~/.codex/sqlite -maxdepth 1 -type f \
\( -name '.sqlite' -o -name '.sqlite-wal' -o -name '*.sqlite-shm' \) \
-exec mv {} ~/.codex/db-backups/manual-backup/ \;

Then I clicked Retry / restarted Codex, and Codex recreated fresh SQLite files automatically.

Notes:

• I backed up the files instead of deleting them.
• Moving only .sqlite files was not enough because SQLite also had -wal and -shm sidecar files.
• The key extra fix was creating ~/.codex/db-backups, because Codex’s built-in recovery was failing when that

directory was missing.

One caveat: the simple command above flattens files from ~/.codex/sqlite into the same backup folder. What I
actually ran preserved the sqlite/ subfolder too, but for most users the simpler version is probably enough unless
there are filename collisions.

Claude fixed my issue:

The dialog was misleading — your database was never actually corrupt (integrity_check and quick_check both returned ok). The real problem was a crash-looping process stack: a background codex app-server daemon and a codex-aar helper kept dying and respawning, each grabbing a lock on state_5.sqlite, so every relaunch failed to initialize the sqlite runtime. The in-app "Back Up and Rebuild" button couldn't help because it had its own bug (ENOENT … mkdir 'db-backups' — it tries to create that folder from a working directory that no longer exists).

What I did:

• Killed the entire Codex.app process tree.
• Confirmed all databases were released.
• Folded the stray large write-ahead log back into logs_2.sqlite (wal_checkpoint(TRUNCATE)), verified integrity.
• Relaunched Codex — the app-server is now stable and got all the way past DB init into normal network operation. No more sqlite/db-backups errors in the log.

Fully close the app, then in the terminal run

pkill -f Codex
pkill -f codex

Then try restarting the app