Skip to content

WSL agent environment corrupts local state_5.sqlite migration on Windows #23841

Open
Open
WSL agent environment corrupts local state_5.sqlite migration on Windows#23841
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

Description

@daikihashimoto95
daikihashimoto95
opened on May 21, 2026

Environment

  • Windows 10 Home
  • Version: 2009
  • Build: 26200
  • Architecture: 64-bit

WSL

  • WSL version: 2.3.26.0
  • Kernel version: 5.15.167.4-1
  • Distro: Ubuntu (WSL2)

Installed distros:

Ubuntu             Running   Version 2
docker-desktop     Running   Version 2

Codex local directory

C:\Users\daiki\.codex

WSL accesses the same directory through:

/mnt/c/Users/daiki/.codex

Reproduction Steps

  1. Launch Codex normally on Windows
  2. Existing .codex directory and local chat history already present
  3. Open Codex settings
  4. Change:
Agent environment -> WSL
  1. Restart Codex
  2. Codex fails during startup with:
error: while executing migration 1:
migration 1 was previously applied but has been modified

Observed Behavior

  • state_5.sqlite becomes unusable
  • Existing chat history cannot be loaded
  • Restoring the previous .codex directory reproduces the same error
  • Renaming .codex allows Codex to launch again with a fresh state

Expected Behavior

Switching to WSL agent mode should not invalidate existing SQLite migrations or corrupt local state/history.

Additional Diagnostics

Relevant files

state_5.sqlite
state_5.sqlite-shm
state_5.sqlite-wal
logs_2.sqlite

Notes

  • No manual modification of SQLite files
  • No custom CODEX_HOME
  • No symlink setup
  • Problem started immediately after enabling WSL agent mode
  • Looks related to migration checksum mismatch between Windows and WSL environments

Activity

  1. daikihashimoto95
    added
    appIssues related to the Codex desktop app
    on May 21, 2026
  2. github-actions
    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

  3. github-actions commented on May 21, 2026

    @github-actions
    github-actionsbot
    on May 21, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. ibdevio commented on May 21, 2026

    @ibdevio
    ibdevio
    on May 21, 2026

    same problem
    any fixes?

  5. daikihashimoto95 commented on May 21, 2026

    @daikihashimoto95
    daikihashimoto95
    on May 21, 2026
    Author

    Deleting the .codex directory and restarting Codex fixed the startup issue for me, but it also wiped all local chat history.

    At the moment I don't know a way to recover/fix the migration issue while preserving the existing chat history database.

  6. ibdevio commented on May 21, 2026

    @ibdevio
    ibdevio
    on May 21, 2026

    but deleting .codex directory changes WSL to Windows Native as well

  7. daikihashimoto95 commented on May 21, 2026

    @daikihashimoto95
    daikihashimoto95
    on May 21, 2026
    Author

    You're right. I forgot to mention that.

    Deleting the .codex directory also reset the agent environment setting from WSL back to Windows Native. But to be clear, that was just a workaround to get it launching again, not a proper fix for the underlying issue.

  8. sabruss commented on May 21, 2026

    @sabruss
    sabruss
    on May 21, 2026

    when i perform an app refresh on a fresh .codex directory to allow wsl again it crash again with the same issue

  9. lim-0 commented on May 21, 2026

    @lim-0
    lim-0
    on May 21, 2026

    same issue

  10. ibdevio commented on May 21, 2026

    @ibdevio
    ibdevio
    on May 21, 2026

    when i perform an app refresh on a fresh .codex directory to allow wsl again it crash again with the same issue

    yeah. same

  11. sabruss commented on May 21, 2026

    @sabruss
    sabruss
    on May 21, 2026

    I may have found a temporary workaround.

    First, install the Codex CLI package wsl side:

    # Using npm
npm install -g @openai/codex

# Using Homebrew
brew install --cask codex

    Then set the CODEX_HOME environment variable so it points to the Windows .codex directory and run codex CODEX_HOME=/mnt/c/Users/username/.codex codex

    Codex should detect the corrupted database and repair it.

    Image

    Once the repair is complete, the Codex app should be able to run with WSL support again.

  12. ChouUn commented on May 21, 2026

    @ChouUn
    ChouUn
    on May 21, 2026

    Then set the CODEX_HOME environment variable so it points to the Windows .codex directory: export CODEX_HOME=/mnt/c/Users/username/.codex

    restart the terminal then run codex

    @sabruss it works, thx.
    btw, we can run CODEX_HOME=/mnt/c/Users/username/.codex codex in one line to avoid the restarting.

  13. sunbin998 commented on May 21, 2026

    @sunbin998
    sunbin998
    on May 21, 2026

    thank you. it works.

  14. jshaofa-ui commented on May 21, 2026

    @jshaofa-ui
    jshaofa-ui
    on May 21, 2026

    Technical Solution for WSL State Corruption

    Root Cause

    NOT actual database corruption — it is a CRLF/LF line ending mismatch in SQLx migration checksums:

    • Windows binaries embed SQL migration files with CRLF (\r\n) line endings
    • WSL/Linux binaries embed the same SQL files with LF (\n) line endings
    • SQLx validates migrations using byte-for-byte SHA-384 checksums, so sha384(CRLF) != sha384(LF)
    • When a user switches from Windows Native to WSL agent mode, the WSL binary rejects the database

    Proposed Fix (4-part)

    1. Build-time normalization — .gitattributes + normalize_migration_sql() to ensure consistent line endings
    2. Automatic checksum repair on startup — recovers affected users without data loss
    3. Graceful error with recovery instructions — defensive UX improvement
    4. Per-environment DB separation — optional architectural improvement

    Code Changes

    • .gitattributes: Add * text=auto eol=lf for SQL files
    • crates/codex-sqlx/src/migration.rs: Add normalize_migration_sql() + checksum repair
    • crates/codex-app/src/db.rs: Add per-environment DB path

    Test Plan

    • Unit: Verify line ending normalization
    • Integration: Switch between Windows/WSL, verify DB compatibility
    • Manual: Reproduce original issue, verify recovery

    Impact

    • Severity: CRITICAL — data corruption for WSL users
    • Risk: LOW — fix is additive, backward compatible
    • Estimated Value: $2,000–$3,000

    Full solution: solutions/codex-23841-wsl-agent-corrupts-state-sqlite-fix.md

  15. xdifu commented on May 21, 2026

    @xdifu
    xdifu
    on May 21, 2026

    This looks like the same CRLF/LF SQLx checksum mismatch tracked in #23777 and #23787. Switching a Windows-created CODEX_HOME to the WSL backend can make the Linux binary expect LF-hashed migrations while the existing SQLite DB has CRLF-hashed _sqlx_migrations rows. Deleting .codex gets the app launching again, but it loses the existing local history metadata.

    For a non-destructive recovery path, I published a small Apache-2.0 toolkit here: 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 doctor
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 extracts the expected checksums from the active Codex backend binary, schema-verifies before any write, backs up state_5.sqlite / logs_2.sqlite, and can also finish the state backfill outside the 30s GUI timeout. sessions/*.jsonl stays read-only.

  16. Soulsolder commented on May 21, 2026

    @Soulsolder
    Soulsolder
    on May 21, 2026

    it's actually logs_2.sqlite
    solved here:
    #23863

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