Skip to content

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

Open

Description

@leonardofoderaro

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:

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

Activity

  1. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 21, 2026
  2. colinmcdermott commented on May 21, 2026

    @colinmcdermott

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

  3. leonardofoderaro commented on May 22, 2026

    @leonardofoderaro
    Author

    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.

  4. xdifu commented on May 23, 2026

    @xdifu

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions