›_ Codex Issues
Codex Issues / #23893

Codex App for Windows: WSL2 agent mode blocks launch due to SQLite migration mismatch

Open 💬 4 comments Opened May 21, 2026 by leonardofoderaro
💡 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

What subscription do you have?

Enterprise

What platform is your computer?

Windows11 / WSL2

What issue are you seeing?

Hi OpenAI Support,

I’m reporting a launch-blocking issue in Codex App for Windows when switching the agent mode to WSL2.

Environment:

  • Codex App for Windows version: 26.519.2081.0
  • Windows user: workstation\leona
  • WSL distro: Ubuntu, WSL version 2
  • wsl -l -v shows Ubuntu as Running, version 2
  • WSL user: leo
  • WSL home: /home/leo
  • bubblewrap is installed: /usr/bin/bwrap, version 0.4.0
  • Codex Windows native/auto mode still launches

Actual result:
Codex shows a modal saying:

“Codex cannot access its local database.
The app cannot finish launching until its SQLite database is accessible.”

The error text is:

Database path: /mnt/c/Users/leona/.codex/state_5.sqlite
failed to initialize state runtime at /mnt/c/Users/leona/.codex

Error:
(code=-1, signal=null)

Most recent error:
failed to initialize sqlite state db at /mnt/c/Users/leona/.codex/state_5.sqlite:
failed to initialize state runtime at /mnt/c/Users/leona/.codex:
migration 1 was previously applied but has been modified

Expected result:
Codex App should launch in WSL2 agent mode and allow the agent to access the WSL filesystem, e.g. /home/leo.

Additional observations:

  • In Windows native mode, Codex commands run under workstation\codexsandboxoffline, so they cannot see the WSL distro registered under workstation\leona.
  • If a command is approved outside the sandbox, it runs as workstation\leona and can access WSL successfully.
  • The SQLite database exists at C:\Users\leona\.codex\state_5.sqlite.
  • The _sqlx_migrations table contains migrations 1 through 32.
  • This looks like a migration checksum/version mismatch between the Windows-native state database and the WSL2 agent startup path.
  • This is not a missing WSL/bubblewrap problem: Ubuntu WSL2 is running and bwrap is installed.

Related public reports/issues:

  • openai/codex #21750: state runtime can wedge startup on state_5.sqlite failures, with no automatic recovery:

https://github.com/openai/codex/issues/21750

  • openai/codex #20493: Codex Desktop update/import issue involving broken state_5.sqlite and manual DB recovery:

https://github.com/openai/codex/issues/20493

  • openai/codex #17991: Windows desktop / WSL issue that also mentions a separate repaired state_5.sqlite migration mismatch:

https://github.com/openai/codex/issues/17991

  • Reddit report with the same exact error text after update on Windows/WSL:

https://www.reddit.com/r/u_Embarrassed-Top-8198/comments/1tjechb/fix_for_codex_migration_1_was_previously_applied/

Workaround:
Switching back to Windows native/auto mode lets Codex launch again, but WSL2 agent mode remains unusable.

Thanks!
Leonardo

What steps can reproduce the bug?

  1. Open Codex App on Windows.
  2. Go to Settings.
  3. Change the agent mode from Windows native/auto to WSL2.
  4. Restart the app.
  5. Codex does not finish launching.

What is the expected behavior?

The agent should run in WSL2

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23848
  • #23841
  • #23824
  • #23777
  • #23863

Powered by Codex Action

colinmcdermott · 3 months ago

Experiencing this also. First time using the app and have to use Powershell or use Codex via CLI.

leonardofoderaro · 3 months ago

The Codex desktop sandbox is not running under my normal Windows user. In my case the app shell was running as WORKSTATION\codexsandboxoffline, while my Ubuntu WSL distro is registered under WORKSTATION\leona.

Because WSL distros are per-Windows-user, wsl.exe inside the sandbox reports no distro/default distro, even though Ubuntu exists for my real user.

The workaround that worked for me was to run WSL commands outside the sandbox and target the distro explicitly:

wsl.exe -d Ubuntu -- <command>

For example:

wsl.exe -d Ubuntu -- ls -la /home/leo

So the app probably needs to dispatch WSL commands through the host user’s WSL context, or at least preserve the correct Windows user/distro mapping when launching agents.

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.