›_ Codex Issues
Codex Issues / #23848

Fixed: share how to fix, Codex GUI failed to launch because it could not initialize its local SQLite state DB.

Open 💬 11 comments Opened May 21, 2026 by roccho-dev
💡 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.2081.0_x64

What subscription do you have?

chatgpt pro

What platform is your computer?

Windows 10 Enterprise

What issue are you seeing?

## Summary

Codex GUI failed to launch because it could not initialize its local SQLite state DB.

Screenshot error:

> Codex cannot access its local database.
> Database path: /mnt/c/Users/<user>/.codex/state_5.sqlite
> migration 1 was previously applied but has been modified

<img width="546" height="301" alt="Image" src="https://github.com/user-attachments/assets/381b10b6-aa45-4ce4-bb19-f899b09b1a8a" />

## Environment

  • OS: Windows 10 Enterprise 10.0.26100.4652
  • Build lab: 26100.1.amd64fre.ge_release.240331-1435
  • Codex app: OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0
  • WSL: 2.7.3.0
  • WSL kernel: 6.6.114.1-1
  • WSLg: 1.0.73

## Likely Cause

Codex GUI had WSL mode enabled:

  • runCodexInWindowsSubsystemForLinux = true
  • active workspace root was under \\wsl$\NixOS\...

Because of that, the Windows Codex home:

C:\Users\<user>\.codex

was accessed from WSL as:

/mnt/c/Users/<user>/.codex

The SQLite state DB then hit a migration mismatch:

migration 1 was previously applied but has been modified

## Workaround That Fixed It

  1. Backed up .codex settings.
  2. Disabled GUI WSL mode:
  • runCodexInWindowsSubsystemForLinux = false
  • integratedTerminalShell = powershell
  • active workspace root reset to C:\Users\<user>
  1. Moved these SQLite files out of .codex:
  • state_5.sqlite*
  • logs_2.sqlite*
  1. Restarted Codex GUI.

Codex regenerated the SQLite DBs and launched successfully.

## Notes

Please do not ask users to attach full .codex contents, since it may contain auth data and conversation history.

What steps can reproduce the bug?

as above

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 2 months ago

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

  • #23841
  • #23777
  • #23787
  • #23251
  • #23824

Powered by Codex Action

xdifu · 2 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.

BadAtCaptchas · 2 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 git clone https://github.com/xdifu/codex-repair.git cd codex-repair python codex-repair.py fix --apply 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.

Thank you! Worked like a charm. The update completely broke my Codex install and your tool fixed it.

lantanios · 2 months ago

Revised GitHub Issue Post (with your activism point included)

Title Suggestion:
Codex Desktop Crashing on Multiple Windows 11 Systems – Urgent Stability Issues

Issue Body:

Description

I am reporting repeated crashes of Codex Desktop across multiple Windows machines. The issue has now affected three separate systems in quick succession.

Reproduction Steps / Timeline

  • Two days ago: Installed Codex Desktop on an older Windows 10 laptop → immediate failure.
  • Last night: Codex Desktop on my primary Windows 11 laptop (fully updated, latest WSL + Ubuntu) suddenly crashed and stopped working.
  • This morning: Same crash occurred on another fully updated Windows 11 desktop with latest WSL.

Environment

  • OS: Windows 11 (latest updates) and Windows 10
  • WSL: Latest version with Ubuntu
  • Codex Desktop: Latest available version

Additional Context

It is already disappointing that the macOS version has the “computer use” feature while Windows users still do not. These widespread crashes on Windows now make the situation significantly worse.

Question for the Codex team: Is anyone actively working on Windows stability issues? Can you confirm if this is a known problem and provide any timeline for resolution?

Additionally, the growing frustration among Windows users raises a broader concern. Would anyone be interested in organizing a collective effort to advocate for better parity and protection of Windows users’ rights and experience with Codex?

<img width="554" height="294" alt="Image" src="https://github.com/user-attachments/assets/26cf4f08-88b1-4cbd-bcac-8e5bbc9a9ad8" />

colinmcdermott · 2 months ago

This is absolutely not fixed

shutupandshave · 2 months ago

I have this on my mac.

LaZzyMan · 1 month ago

i have this on mac after updateto new version!

crousty24-bit · 1 month 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 git clone https://github.com/xdifu/codex-repair.git cd codex-repair python codex-repair.py fix --apply 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.

I confirm it worked just fine. Thank you mate !

ShellaGao · 1 month ago
i have this on mac after updateto new version!

absolutely same situation

AnYu798 · 1 month ago

Thank you very much, this is very helpful to me.

AZagatti · 10 days ago

If you're on Windows + WSL and Codex Desktop suddenly won't launch with:

Error: failed to initialize sqlite state runtime under C:\Users\<you>\.codex

here's what caused it for me and how I fixed it.

Cause: two different Codex builds were writing to the same database. The Windows app uses C:\Users\<you>\.codex. I had also set CODEX_HOME in my WSL shell to point at that same folder, so the Linux codex binary wrote to it too. The two builds use different DB migrations, so whichever ran last left the database in a state the other can't open. Once the Linux build touched it, the Windows app failed to start.

Note: the checksum-repair scripts people are sharing didn't help in this case. Those fix drift inside one build. This is two builds with different schemas, so the only real fix is a clean rebuild.

Fix (chat history is kept):

  1. Fully quit Codex Desktop. Check Task Manager and end any ChatGPT.exe still running.
  2. In C:\Users\<you>\.codex, move these into a backup folder (move, don't delete): state_5.sqlite, logs_2.sqlite, goals_1.sqlite, memories_1.sqlite, including their -wal and -shm files.
  3. Start the app. It rebuilds those databases and re-indexes your history from sessions/*.jsonl.

If it still fails, one of the four databases is probably still there, or the app wasn't fully closed. All four must be gone and the app fully quit before you relaunch.

Stop it recurring: don't point WSL's CODEX_HOME at the Windows /mnt/c/.../.codex. Let the Windows app and WSL each keep their own .codex. Sharing one folder to get history in both places is what breaks it.