[Windows][WSL] All threads fail with invalid transport in mcp_servers.codex_app after update to 26.820.x — WSL app-server stuck at 0.150.0-alpha.8

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

ChatGPT (formerly Codex) desktop for Windows. About dialog: Version 26.820.60940, Released 25 Aug 2026 ("Powered by Codex & OWL") MSIX package at the time the attached logs were captured: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0

What subscription do you have?

Enterprise

What platform is your computer?

Windows 11 x64 with WSL2 (Ubuntu). Agent environment set to WSL (runCodexInWindowsSubsystemForLinux = true, integratedTerminalShell = "wsl").

What issue are you seeing?

After the desktop app updated (2026-08-25), every thread fails in WSL mode — both resuming existing chats and starting brand-new ones. The UI shows:

ChatGPT can't load config.toml, so this thread can't resume. Fix config.toml: invalid transport in mcp_servers.codex_app. After saving the file, reopen the thread.

<img width="1654" height="370" alt="Image" src="https://github.com/user-attachments/assets/d3b07f8e-3372-4510-ae6d-19a70f78779c" />

However, my config.toml contains no mcp_servers.codex_app entry (verified with recursive grep across all config layers on both the Windows and WSL side). The entry appears to be injected by the app itself with each thread/start / thread/resume request.

Windows-native mode works fine. Only WSL mode is broken, which points to a version/pairing mismatch between the updated app and the WSL-side app-server.

Evidence from desktop logs (attached)

1. The app spawns the WSL app-server from the legacy provisioning path, and it reports an old version:

• stdio_transport_spawned ... coreRuntimeInUse=false executablePath=C:\Users\<user>\.codex\bin\wsl\bf0dd1e87d338bce\codex spawnCommand=wsl.exe
• Current reported app-server version: currentVersion=0.150.0-alpha.8

1. That backend does not recognize the feature the new UI enables:

• codex_app_server::request_processors::config_processor: ignoring invalid experimental feature enablement keys: apps_mcp_path_override
• (the renderer's enabled features include apps_mcp_path_override, enable_mcp_apps, apps, ...)

1. Every thread request then fails during config load:

• Request failed ... method=thread/start ... error={"code":-32600,"message":"failed to load configuration: invalid transport\nin mcp_servers.codex_app\n"} failureReason=invalid_config
• Same for thread/resume on existing conversations.

1. The installed package appears to be missing part of the legacy WSL payload:

• bundled_executable_relocation_failed destinationPath=C:\Users\<user>\.codex\bin\wsl\codex-resources\bwrap errorCode=ENOENT — the source file C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\resources\codex-resources\bwrap does not exist (stat_source fails).

1. The new runtime system does list a current Linux artifact, but it is not used for the WSL app-server:

• Codex runtime config selected artifact=codex-primary-runtime ... bundleVersion "26.819.11345" with platforms including linux-x86_64 — yet coreRuntimeInUse=false and the stale 0.150.0-alpha.8 binary is spawned instead.

What I already tried (no effect unless noted)

• Fully quit app + wsl --shutdown, deleted the C:\Users\<user>\.codex\bin\wsl cache → re-provisioned the same bf0dd1e87d338bce / 0.150.0-alpha.8 binary.
• Settings → Apps → ChatGPT → Advanced options → Repair (completed successfully after Terminate + wsl --shutdown) → error persists, same backend version.
• Website installer → reports "The latest version is installed" (same build).
• Set enabled = false under [plugins."codex-app-tools@openai-bundled"] in config.toml → no effect.
• Switched agent environment to Windows-native → everything works; switching back to WSL mode → error returns immediately.

Expected behavior

In WSL mode, the app should provision/spawn a WSL app-server that matches the app version (or use the linux-x86_64 artifact from codex-primary-runtime), so that the injected mcp_servers.codex_app configuration parses. If the backend is older, the app should degrade gracefully instead of failing every thread/start/thread/resume.

Possibly related

• #30378 (apps_mcp_path_override rejected by app-server, VS Code + WSL)
• #29396 (invalid transport in mcp_servers.codex_apps config parse error class)

Attachments

• Desktop log from initial failure (2026-08-25 21:35)
• Desktop log after cache wipe, same failure (2026-08-25 21:56)
• config.toml

codex-desktop-fb1cceb1-f589-4cae-9335-7eb1f559aad6-23452-t0-i1-213523-0.log

codex-desktop-40fd35a2-7872-4664-aa55-519c9180b809-37868-t0-i1-215614-0.log

config.toml.txt

What steps can reproduce the bug?

Preconditions:

• Windows 11 x64 with WSL2 (Ubuntu)
• ChatGPT (Codex) desktop 26.820.60940 / package 26.820.7780.0
• Settings: Agent environment = Windows Subsystem for Linux, integrated terminal = WSL

Steps:

1. Launch the app.
2. Start a brand-new chat in any project (or open any pre-existing thread).
3. Send any prompt (e.g. "hello").

Actual: Every thread immediately fails with the banner
"ChatGPT can't load config.toml, so this thread can't resume. Fix config.toml: invalid transport in mcp_servers.codex_app."
No prompt is ever processed. Reproduces 100% of the time, on new and old threads alike,
e.g. local thread id 01a02e8a-946b-7651-9c9c-3f8f938a7c89 (see attached logs at 21:35:42 and 21:56:30).

Expected: The thread starts and the prompt is processed.

Note: Switching Agent environment to Windows-native makes everything work;
switching back to WSL reproduces the error immediately. config.toml contains no
mcp_servers.codex_app entry (verified by recursive grep on both Windows and WSL side) —
the entry appears to be injected by the app at thread/start.

What is the expected behavior?

In WSL mode, the app should provision/spawn a WSL app-server that matches the app version (or use the linux-x86_64 artifact from codex-primary-runtime), so that the injected mcp_servers.codex_app configuration parses. If the backend is older, the app should degrade gracefully instead of failing every thread/start/thread/resume.

Additional information

_No response_