›_ Codex Issues
Codex Issues / #23780

Codex Windows App reported an error after upgrading: Codex cannot access its local database

Resolved 💬 2 comments Opened May 20, 2026 by davidjqq19 Closed May 20, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.21041

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

<img width="553" height="335" alt="Image" src="https://github.com/user-attachments/assets/058ee701-29e0-4d60-a9b6-5546b08c257e" />

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23777
  • #23251

Powered by Codex Action

xdifu · 3 months ago

This is the same root-cause family as #23777 / #23787: the WSL/Linux Codex backend rejects a Windows-created SQLite DB because SQLx migration checksums differ at the CRLF-vs-LF byte level. Moving state_5.sqlite* / logs_2.sqlite* aside is a launch workaround, but it forces Codex to rebuild metadata instead of repairing the existing DBs.

For users who want to preserve local history metadata, I published a non-destructive repair tool: https://github.com/xdifu/codex-repair

Windows PowerShell / Windows Terminal:

git clone https://github.com/xdifu/codex-repair.git
cd codex-repair
python codex-repair.py fix --apply

If you run it from WSL bash to repair Windows Codex Desktop data, pass --codex-home "/mnt/c/Users/<WindowsUser>/.codex" so it does not target WSL's own ~/.codex.

It backs up the SQLite DBs, extracts the active backend's expected checksums, schema-verifies before rewriting _sqlx_migrations, and leaves ~/.codex/sessions/*.jsonl read-only.