WSL CLI cannot share Windows Codex App CODEX_HOME: migration 1 was previously applied but has been modified

Looks like there's a fix in the works, but in the meantime I was able to do the following as a workaround - the sql lite file locations default to the main .codex directory, but if you make them their own directory and then assign the new path to a variable, it seems to allow codex to use them from WSL correctly. This involved setting a WSL env variable and a TOML variable - not sure if both are required, but this is what worked for me.

I am using a company-managed laptop (no admin access) with windows 11 and WSL Ubuntu 2

• Close Codex
• Open WSL
• If you haven't already, open up your ~\.bashrc file in nano or whatever and set CODEX_HOME to /mnt/c/Users/<user_name>/.codex
• While you are there, also set CODEX_SQLITE_HOME to /mnt/c/Users/<user_name>/.codex/sqlite-wsl

export CODEX_HOME="/mnt/c/Users/<user_name>/.codex"
export CODEX_SQLITE_HOME="/mnt/c/Users/<user_name>/.codex/sqlite-wsl"

• Go to .codex and backup all your existing .sqlite files, create a new folder called sqlite-wsl

cd "/mnt/c/Users/<user_name>/.codex"
mkdir db-backup
mv ./state_5.sqlite* db-backup/
mv ./logs_2.sqlite* db-backup/
mkdir sqlite-wsl

• Exit WSL and shutdown from windows shell:

wsl --shutdown

• Modify config.toml, add line:

sqlite_home = "/mnt/c/Users/<user_name>/.codex/sqlite-wsl"

• Start Codex

Fair warning - even after starting, I had to do a bit more fiddling to get a terminal session running, and I had to manually install bubblwrap in WSL for some reason:

apt-get install -y bubblewrap

Looks like there's a fix in the works, but in the meantime I was able to do the following as a workaround - the sql lite file locations default to the main .codex directory, but if you make them their own directory and then assign the new path to a variable, it seems to allow codex to use them from WSL correctly. This involved setting a WSL env variable and a TOML variable - not sure if both are required, but this is what worked for me. I am using a company-managed laptop (no admin access) with windows 11 and WSL Ubuntu 2 Close Codex Open WSL If you haven't already, open up your ~\.bashrc file in nano or whatever and set CODEX_HOME to /mnt/c/Users/<user_name>/.codex While you are there, also set CODEX_SQLITE_HOME to /mnt/c/Users/<user_name>/.codex/sqlite-wsl export CODEX_HOME="/mnt/c/Users/<user_name>/.codex" export CODEX_SQLITE_HOME="/mnt/c/Users/<user_name>/.codex/sqlite-wsl" Go to .codex and backup all your existing .sqlite files, create a new folder called sqlite-wsl cd "/mnt/c/Users/<user_name>/.codex" mkdir db-backup mv ./state_5.sqlite db-backup/ mv ./logs_2.sqlite db-backup/ mkdir sqlite-wsl Exit WSL and shutdown from windows shell: wsl --shutdown Modify config.toml, add line: sqlite_home = "/mnt/c/Users/<user_name>/.codex/sqlite-wsl" Start Codex Fair warning - even after starting, I had to do a bit more fiddling to get a terminal session running, and I had to manually install bubblwrap in WSL for some reason: apt-get install -y bubblewrap

life savior

This is now covered by the same CRLF/LF SQLx checksum root cause tracked in #23777 and #23787. A Windows-created Codex App CODEX_HOME can contain CRLF-hashed migration rows, while the WSL/Linux backend expects LF-hashed rows and refuses to open the same state_5.sqlite / logs_2.sqlite.

I published a non-destructive recovery 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 auto-detects the active backend binary, extracts the expected migration checksums, verifies the live schema before any update, backs up both SQLite DBs, and preserves sessions/*.jsonl as read-only. This is meant as a safer alternative to moving/deleting the DBs or accepting the destructive repair prompt.

@xdifu Brilliant, worked flawless here, thank you!

@thollands thank you!

@thollands your solution can work well with cc-switch ! thank you !

I am seeing a very similar Windows/WSL state failure today, now through the VS Code Codex extension as well as Desktop/CLI sharing.

Environment:

• Windows 10 Pro build 19045
• WSL Ubuntu 22.04.5 LTS, kernel 6.6.114.1-microsoft-standard-WSL2
• Codex Desktop package OpenAI.Codex 26.519.3891.0
• VS Code extension openai.chatgpt@26.519.32039
• WSL codex --version: codex-cli 0.133.0-alpha.1
• Shared Codex home is under the Windows profile, exposed in WSL as /mnt/c/Users/<user>/.codex

VS Code Codex is stuck on the loading screen. Its extension log shows:

[CodexMcpConnection] Spawning codex app-server
[CodexMcpConnection] cli: message="codex_app_server: failed to initialize sqlite state db: failed to initialize state runtime at C:\Users\<user>\.codex: migration 1 was previously applied but has been modified"
[CodexMcpConnection] Initialize received id=1

I also hit a related Desktop/CLI reliability problem yesterday after a Codex Desktop auto-update involving bundled binary/runtime mismatch and backfill-timeout behavior. Today, Desktop is still technically responding, but trivial prompts on fast mode with gpt-5.5 / medium reasoning / priority service tier are taking 25-63s per turn, while VS Code Codex is blocked by the migration mismatch above.

This strongly suggests the Windows app, VS Code extension, and WSL CLI can still get into incompatible runtime/state combinations when sharing CODEX_HOME, and the failure mode leaves the VS Code extension stuck loading rather than presenting a non-destructive recovery path.

Follow-up with a more controlled timing matrix from the same Windows/WSL machine, after the VS Code loading-screen failure was locally recovered.

Environment:

• Windows 10 / WSL Ubuntu 22.04
• Codex Desktop package OpenAI.Codex 26.519.3891.0
• VS Code extension openai.chatgpt@26.519.32039
• CLI version in both paths: codex-cli 0.133.0-alpha.1

Observed split:

• VS Code WSL Codex is now fast again: hello around 2-4s, factual query around 6-8s.
• Codex Desktop/new Desktop chat stayed slow: hello around 18s, trivial/factual turns around 38s in one fresh chat.
• The current Desktop app-server environment uses a Windows-backed Codex home from WSL, while VS Code WSL uses the Linux-side Codex home.

Controlled CLI timings for Reply exactly: <probe>-pong:

| Probe | Result |
| --- | ---: |
| WSL CLI, Desktop env / Windows-backed Codex home | 39.257s |
| WSL CLI, same env, --disable plugins --disable apps | 10.868s |
| WSL CLI, Linux-side Codex home | 4.823s |
| WSL CLI, Linux-side Codex home, --disable plugins --disable apps | 3.092s |
| Existing Windows codex.exe from VS Code extension | 9.208s |
| Existing Windows codex.exe, --disable plugins --disable apps | 3.665s |

Temporary mitigation applied locally:

[features]
apps = false
plugins = false

After that, normal WSL CLI probes from the Desktop environment improved to:

• gpt-5.4: 9.665s
• gpt-5.5: 7.610s

The plugin catalog 403/Cloudflare challenge warnings disappeared after disabling apps/plugins, but codex_rollout::list ... state db discrepancy ... falling_back warnings remain. This seems to be two overlapping issues: plugin/app startup work causing large latency spikes, and Windows/WSL Codex-home/state behavior causing fallback/migration problems.