Windows Desktop: `invalid transport in mcp_servers.codex_app` breaks every chat when runCodexInWindowsSubsystemForLinux=true

Bug: invalid transport in mcp_servers.codex_app breaks every chat when runCodexInWindowsSubsystemForLinux = true

Summary

On Windows, with the Codex Desktop setting "Run Codex in WSL" enabled (runCodexInWindowsSubsystemForLinux = true in config.toml), every attempt to start or resume a chat fails with:

failed to load configuration: invalid transport
in `mcp_servers.codex_app`

This affects new chats, resuming existing threads, subagent/task routing, and loading older thread history. The app is effectively unusable in WSL mode. Disabling runCodexInWindowsSubsystemForLinux (falling back to native Windows execution) immediately and reliably fixes it, which isolates the bug to the Desktop's WSL code path specifically, not to the user's WSL environment, Node/npm installation, or CLI.

Environment

• Codex Desktop version: 26.820.7780.0 (AppX package OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0, installed via Microsoft Store)
• OS: Windows 11 Pro
• WSL distro: Ubuntu, with Node/npm/Codex CLI installed natively inside WSL via nvm (verified Linux-native, not /mnt/c/... shims)
• Windows Codex CLI: codex-cli 0.147.0 (C:\Users\<user>\AppData\Roaming\npm\codex)
• Relevant config.toml plugin: codex-app-tools@openai-bundled (bundled, enabled = true)

Root cause (confirmed)

The bundled plugin codex-app-tools@openai-bundled registers an MCP server named codex_app, defined in:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\codex-app-tools\0.1.3\desktop-mcp.json

{
  "mcpServers": {
    "codex_app": {
      "command": "cmd.exe",
      "args": ["/d", "/s", "/c", "call", "./scripts/launch_codex_app_tools_mcp.cmd", "./server.mjs"],
      "cwd": ".",
      "enabled": true,
      ...
    }
  }
}

This is a Windows-only transport (cmd.exe launching a .cmd script). It appears to be an internal/core mechanism — its tools (create_thread, fork_thread, handoff_thread, send_message_to_thread, automation_update) back subagent/thread orchestration, not an optional user-facing integration. Setting [plugins."codex-app-tools@openai-bundled"] enabled = false in config.toml has no effect on the error — the server is still loaded and still fails, confirming it isn't gated by the normal plugin toggle.

When runCodexInWindowsSubsystemForLinux = true, the Desktop's backend (app-server) runs inside WSL (every request is preceded by [spawn-async] Spawning process inside WSL in the logs). A Linux/WSL-hosted backend process cannot resolve cmd.exe as a valid transport, so the config loader rejects the codex_app server with invalid transport, and every thread/start call fails.

Reproduction (local, controlled A/B test)

Log source: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\...

A. runCodexInWindowsSubsystemForLinux = true (default/current):

2026-08-26T15:55:11.232Z info [AppServerConnection] response_routed ... errorCode=-32600 ... method=thread/start ...
2026-08-26T15:55:11.238Z warning [electron-message-handler] Failed to prewarm conversation cwd=/mnt/c/Users/<user>/... errorMessage="failed to load configuration: invalid transport\nin `mcp_servers.codex_app`\n" ...

Immediately preceded by [spawn-async] Spawning process inside WSL. 125+ occurrences logged across multiple sessions; happens on startup prewarm, on thread/start for a new chat, on resuming any existing conversation, and on loading older thread history.

B. Same install, same config.toml, only runCodexInWindowsSubsystemForLinux flipped to false:

2026-08-26T15:57:06.953Z info [AppServerConnection] response_routed ... errorCode=null ... method=thread/start ...
2026-08-26T15:57:11.466Z info [AppServerConnection] response_routed ... errorCode=null ... method=thread/start ...

No invalid transport anywhere, no Spawning process inside WSL lines at all, and a real chat message was sent and processed successfully.

Nothing else was changed between A and B — same config.toml (only that one boolean), same plugins, same MCP servers, same machine, same WSL install.

Why this matters

Restoring runCodexInWindowsSubsystemForLinux = false is not an acceptable workaround for users who depend on WSL for their Codex workflows (paths under /mnt/..., WSL-based MCP servers, Linux-native tooling) — it silently moves execution to a different environment. There is currently no other way to avoid the bug:

• No official channel exists to install an older, working Desktop build — the app updates automatically via Microsoft Store, which does not expose historical versions, and github.com/openai/codex/releases does not distribute the Desktop MSIX at all (only CLI binaries). See #26914, which requests exactly this capability and has no maintainer response.
• Disabling the codex-app-tools plugin does not help (see above).

Suggested fix directions

1. Give codex_app's transport a WSL-aware launcher (e.g. detect when the backend is running inside WSL and invoke the Windows-side script via cmd.exe /c through the WSL→Win32 interop path, the same way wsl.exe-based MCP servers are already invoked from the Windows side in reverse), or
2. Run codex_app as a Windows-side companion process regardless of where the main backend/app-server runs, rather than requiring it to spawn from within the WSL process, or
3. At minimum, make this specific MCP server failure non-fatal — right now it hard-fails thread/start for the entire app instead of just disabling the one feature (thread handoff/subagent routing) that depends on it.

Related

• #26914 — Need a way to select specific Codex desktop versions (would also mitigate this by allowing rollback)

Happy to provide full log excerpts, config.toml (redacted), or run further diagnostics on request.

Start with the bundled plugin definition at %USERPROFILE%.codex\plugins\cache\openai-bundled\codex-app-tools\0.1.3\desktop-mcp.json and trace the app-server path used when runCodexInWindowsSubsystemForLinux is true. Reproduce with thread/start and inspect the WSL spawn logs. Done means WSL mode no longer rejects mcp_servers.codex_app and new or resumed chats can start without invalid transport.