codex - 💡(How to fix) Fix WSL app-server remains active after switching back to Windows and breaks Windows sandbox setup

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Fix Action

Fix / Workaround

Minimal recovery workaround found:

  • Close Codex Desktop.
  • Change this line in C:\Users<user>.codex\config.toml: runCodexInWindowsSubsystemForLinux = true to: runCodexInWindowsSubsystemForLinux = false
  • Restart Codex Desktop.

This workaround is smaller than deleting the entire .codex directory, but it does not fix the underlying recurrence when switching Windows -> WSL -> Windows again.

RAW_BUFFERClick to expand / collapse

What version of the Codex App are you using (From “About Codex” dialog)?

Local logs/package paths observed during debugging referenced: - OpenAI.Codex_26.519.2081.0_x64 - release=26.519.21041

What subscription do you have?

Pro

What platform is your computer?

Windows, using Codex Desktop with both Windows Agent Environment and WSL Agent Environment.

What issue are you seeing?

After switching Codex Desktop Agent Environment from Windows to WSL and then back to Windows, Windows sandbox setup stops working correctly.

When the UI is back on Windows, the local app-server still appears to be launched through WSL instead of the Windows native Codex executable. In the broken state:

  • Desktop logs show the local app-server launched with:
    • spawnCommand=wsl.exe
    • executablePath=C:\Users<user>.codex\bin\wsl...\codex
  • In the same run, Codex Desktop still calls:
    • windowsSandbox/readiness
    • windowsSandbox/setupStart
  • windowsSandbox/setupStart is then repeated many times.
  • Logs also show mixed WSL/Windows paths such as:
    • /mnt/c/...
    • /home/...
    • C:\home...

This makes it look like Codex Desktop has not fully switched the local app-server state back from WSL to Windows native mode before attempting Windows sandbox setup.

Deleting C:\Users<user>.codex temporarily recovers the app, but the problem reproduces again after switching Windows -> WSL -> Windows.

What steps can reproduce the bug?

  1. Start Codex Desktop on Windows.
  2. Use the Windows Agent Environment and confirm it works normally.
  3. Switch Agent Environment to WSL.
  4. Switch Agent Environment back to Windows.
  5. Try to use Windows sandbox setup again.
  6. Observe that Windows sandbox setup does not complete normally and may repeatedly attempt setup.

Observed after reproduction:

  • C:\Users<user>.codex\config.toml still had: runCodexInWindowsSubsystemForLinux = true
  • The latest Desktop log still showed the local app-server spawning via wsl.exe even though the UI had been switched back to Windows.

What is the expected behavior?

When Agent Environment is switched back from WSL to Windows:

  1. Codex Desktop should fully restore the Windows native local app-server.
  2. The local app-server should be launched with the Windows Codex executable, not wsl.exe.
  3. Windows sandbox readiness/setup should run only against the Windows native app-server state.
  4. The WSL selection state should not remain active after returning to Windows.

Additional information

Debugging evidence from the same machine:

Broken state:

  • Latest Desktop log showed: stdio_transport_spawned ... spawnCommand=wsl.exe executablePath=C:\Users<user>.codex\bin\wsl...\codex
  • The same log showed: windowsSandbox/readiness repeated windowsSandbox/setupStart calls
  • The same log showed WSL/Windows path mixing, including C:\home... failures.

Known-good state:

  • After recovery, a normal Windows run showed: stdio_transport_spawned ... spawnCommand="...\WindowsApps...\codex.exe"

Windows sandbox itself does not appear to be permanently damaged:

  • The Windows sandbox log contained successful setup entries such as:
    • WFP setup succeeded
    • setup refresh ... errors=[]
    • setup binary completed

Relevant persisted state observed in the broken state:

  • C:\Users<user>.codex\config.toml contained: runCodexInWindowsSubsystemForLinux = true

Minimal recovery workaround found:

  • Close Codex Desktop.
  • Change this line in C:\Users<user>.codex\config.toml: runCodexInWindowsSubsystemForLinux = true to: runCodexInWindowsSubsystemForLinux = false
  • Restart Codex Desktop.

This workaround is smaller than deleting the entire .codex directory, but it does not fix the underlying recurrence when switching Windows -> WSL -> Windows again.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix WSL app-server remains active after switching back to Windows and breaks Windows sandbox setup