codex - 💡(How to fix) Fix Codex Desktop Windows WSL mode shows reconnecting despite app-server connected

What version of Codex is running?

Codex CLI: 0.129.0

Codex Desktop Windows app: 26.506.2212.0

What subscription do you have?

Not included

Which model were you using?

gpt-5.5

What platform is your computer?

Windows 11 with WSL2

WSL distro:

Ubuntu, WSL version 2
Ubuntu release inside WSL: 26.04

What terminal emulator and version are you using (if applicable)?

Codex Desktop settings:

Agent environment: WSL
Integrated terminal: PowerShell

What issue are you seeing?

Codex Desktop on Windows shows a persistent “reconnecting” / partially broken UI in WSL mode, even though the logs show the WSL app-server successfully starts, the initialize handshake succeeds, and the app-server connection reaches connected.

The issue does not appear to be basic WSL, auth, or Codex CLI connectivity:

• Codex CLI works inside WSL and can reach the model.
• WSL can also run Codex using the Windows Codex home via CODEX_HOME=/mnt/c/Users/<windows-user>/.codex.
• A stable /usr/local/bin/codex wrapper was created so Windows-launched WSL shells can find Codex.
• The app-server transport reaches connected in Desktop logs.
• thread/start and turn/start both appear in logs with errorCode=null.

Key log evidence:

[wsl] eligible distro listResult="NAME      STATE           VERSION\n* Ubuntu    Running         2"
[AppServerConnection] initialize_handshake_result outcome=success
[AppServerConnection] Codex CLI initialized
[AppServerConnection] app_server_connection.state_changed ... next=connected
[AppServerConnection] response_routed ... method=thread/start ... errorCode=null
[AppServerConnection] response_routed ... method=turn/start ... errorCode=null
[electron-message-handler] Conversation created

However, after connection succeeds, Desktop repeatedly logs feature/runtime/app errors:

[electron-message-handler] Failed to sync experimental feature enablement
unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation

[install-primary-runtime] primary_runtime_install_failed
Failed to list primary runtime archive

[electron-message-handler] Failed to load apps list
failed to list apps: Failed to send request

Earlier logs also showed the Windows Electron worker trying to watch Linux paths directly:

ENOENT: no such file or directory, watch '/home/<wsl-user>/codex-test/.git'
ENOENT: no such file or directory, watch '/home/<wsl-user>/codex-test'

That looked like the Windows worker was calling fs.watch() on a Linux path rather than using the WSL UNC path or a WSL-side watcher.

What steps can reproduce the bug?

1. Use Windows 11 with WSL2 and Ubuntu as the default WSL distro.
2. Install Codex CLI inside WSL; CLI works normally and can connect to the model.
3. Install Codex Desktop on Windows.
4. Configure Desktop:

Agent environment: WSL
Integrated terminal: PowerShell

1. Open a clean WSL project, e.g. a git repo under:

\\wsl$\Ubuntu\home\<wsl-user>\test

1. Start Codex Desktop.

What is the expected behavior?

Codex Desktop should recognize the WSL app-server connection as healthy and allow normal interaction without showing persistent “reconnecting”.

What is the actual behavior?

Desktop remains in a “reconnecting” / partially broken state even though the app-server has connected successfully and can route some requests.

Additional information

Things already tried:

• Reinstalled Codex Desktop.
• Reinstalled WSL.
• Confirmed distro name is Ubuntu and WSL version is 2.
• Installed bubblewrap.
• Created /usr/local/bin/codex wrapper so non-interactive Windows-launched WSL shells can find Codex.
• Verified CODEX_HOME=/mnt/c/Users/<windows-user>/.codex codex ... works from WSL.
• Reset C:\Users\<windows-user>\.codex while preserving auth/config.
• Reset Codex app package state/cache.
• Opened a clean WSL git project.
• Cleared .tmp, vendor_imports, plugin/runtime caches.

Network observations from PowerShell:

Invoke-WebRequest https://persistent.oaistatic.com/codex-primary-runtime/latest/win32-x64/LATEST.json
=> 200 OK

Invoke-WebRequest https://chatgpt.com
=> Cloudflare “Enable JavaScript and cookies” challenge page

The runtime manifest endpoint is reachable, but some Desktop-only app/plugin/runtime requests may be hitting Windows-side endpoint/challenge behavior.

The important distinction is that this does not look like a simple WSL app-server startup failure: the app-server connects, but Desktop feature sync / apps / runtime initialization appears to fail afterward.