›_ Codex Issues
Codex Issues / #31426

Windows Desktop WSL agent fails when CODEX_HOME is on /mnt/c due to SQLite/socket state initialization

Open 💬 0 comments Opened Jul 7, 2026 by Bigsunnyboy

Summary

After recent Codex Desktop updates, switching the Windows app's Agent Environment to WSL makes the app/server fail to start on my machine. The WSL installation itself is healthy. The deterministic failure is that the WSL codex app-server cannot initialize its SQLite-backed state when CODEX_HOME points at the Windows profile directory mounted through /mnt/c.

This looks like a Windows Desktop + WSL agent state-location compatibility issue, not a broken WSL installation and not a TOML parse/config syntax issue.

Environment

  • Product: Codex Desktop for Windows
  • Windows app package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0
  • Codex CLI in WSL: codex-cli 0.142.5
  • WSL distro: Ubuntu-22.04
  • WSL kernel: Linux ... 6.6.87.2-microsoft-standard-WSL2 ... x86_64 GNU/Linux
  • bwrap: present at /usr/bin/bwrap
  • Git/Node/Python in WSL: present
  • Windows Codex home as seen from WSL: /mnt/c/Users/Windows11/.codex

Relevant desktop config when WSL mode is enabled:

[desktop]
integratedTerminalShell = "wsl"
runCodexInWindowsSubsystemForLinux = true

I restored the app to Windows-native mode to make it usable again:

[desktop]
integratedTerminalShell = "powershell"
runCodexInWindowsSubsystemForLinux = false

Minimal Reproduction From WSL

Run this from the WSL distro that Codex Desktop detects:

CODEX_HOME=/mnt/c/Users/Windows11/.codex codex app-server --stdio

Actual result:

Error: failed to initialize sqlite state runtime under /mnt/c/Users/Windows11/.codex: failed to initialize state runtime at /mnt/c/Users/Windows11/.codex

The same CLI and WSL environment can initialize app-server when SQLite-backed state is moved to the WSL-native filesystem:

printf '{"jsonrpc":"2.0","method":"initialize","id":0,"params":{"clientInfo":{"name":"diag","title":"diag","version":"0"}}}\n{"jsonrpc":"2.0","method":"initialized","params":{}}\n' \
  | timeout 5s env CODEX_HOME=/mnt/c/Users/Windows11/.codex CODEX_SQLITE_HOME=/root/.codex codex app-server --stdio

Actual result: exits successfully with code 0.

This also works with the normal WSL-local Codex home:

codex app-server --stdio

Additional Deterministic Evidence

A Unix socket can be created on the WSL-native filesystem, but not under the Windows-mounted Codex home.

WSL-native path succeeds:

python3 -c 'import socket, os; d="/tmp/socket-test"; os.makedirs(d, exist_ok=True); p=d+"/test.sock"; os.path.exists(p) and os.unlink(p); s=socket.socket(socket.AF_UNIX); s.bind(p); print("tmp socket ok"); s.close(); os.unlink(p)'

Output:

tmp socket ok

Windows-mounted Codex home fails:

python3 -c 'import socket, os; d="/mnt/c/Users/Windows11/.codex/socket-test"; os.makedirs(d, exist_ok=True); p=d+"/test.sock"; os.path.exists(p) and os.unlink(p); s=socket.socket(socket.AF_UNIX); s.bind(p); print("mntc socket ok"); s.close(); os.unlink(p); os.rmdir(d)'

Output:

OSError: [Errno 95] Operation not supported

This matches the app-server symptoms: WSL/Linux runtime state and local control/socket mechanisms are not safe to place under /mnt/c/Users/.../.codex.

Expected Behavior

When Windows Desktop is configured with runCodexInWindowsSubsystemForLinux = true, the WSL app-server should either:

  1. use a WSL-native path for SQLite/runtime/socket state by default, while still reading shared config/auth as needed; or
  2. detect that CODEX_HOME is on /mnt/c and fail with an actionable diagnostic; or
  3. expose/support a Desktop setting that maps WSL-mode SQLite/runtime state to a Linux-native directory.

Actual Behavior

Switching Codex Desktop to WSL mode makes the app/server unable to start reliably. The WSL environment is otherwise functional, and the same codex app-server initialization succeeds when SQLite state is redirected to /root/.codex through CODEX_SQLITE_HOME.

Why This Does Not Look Like Local Config Corruption

  • config.toml parses successfully.
  • WSL is WSL2, not WSL1.
  • bwrap exists.
  • codex --version works in WSL.
  • codex app-server --stdio works with WSL-local state.
  • The failure is reproducible only when the state root is /mnt/c/Users/Windows11/.codex.
  • Setting CODEX_SQLITE_HOME=/root/.codex is enough to make the app-server initialization succeed while preserving CODEX_HOME=/mnt/c/Users/Windows11/.codex.

Regression / Timeline Note

This setup used to work for normal WSL development. The user-visible breakage started after recent Codex Desktop updates. I cannot provide an old-version A/B binary comparison, so I am not claiming a specific release introduced it. The deterministic evidence is that the current Windows Desktop / WSL-agent path fails when WSL app-server state is rooted under /mnt/c.

Related Issues

These appear related in the broader Windows Desktop + WSL agent/app-server area:

  • #28666: runCodexInWindowsSubsystemForLinux = true with SQLite database locked / launch failure.
  • #30435: WSL agent bad cwd/path and bundled plugin issues.
  • #31049: WSL-native mode hides Chrome bridge tool and passes Windows attachment paths to Linux agent.
  • #16815: WSL agent mode task creation/path handling failure.
  • #13556: WSL mode environment propagation issue after latest update.

Suggested Fix Direction

For WSL agent mode, avoid putting SQLite runtime state and Unix socket/control paths under /mnt/c/.... A split model may be needed:

CODEX_HOME: shared config/auth/plugin metadata location, if needed
CODEX_SQLITE_HOME / app-server-control socket / daemon state: WSL-native filesystem

Alternatively, if WSL mode intentionally requires a WSL-native CODEX_HOME, the Desktop UI should migrate or prompt explicitly instead of using the Windows profile .codex path through /mnt/c.

View original on GitHub ↗