Desktop app 26.820.7780.0: resuming WSL-hosted threads fails with "invalid transport in mcp_servers.codex_app"

Environment

• ChatGPT/Codex desktop app (MS Store, OpenAI.Codex), version 26.820.7780.0, auto-updated 2026-08-26
• Windows 11 + WSL2 Ubuntu 26.04, [desktop] runCodexInWindowsSubsystemForLinux = true
• Bundled codex: 0.150.0-alpha.8 (WSL agent at ~/.codex/bin/wsl/<hash>/codex)
• Affected threads were created with cli 0.149.0-alpha.4.1

Problem

After the app auto-updated to 26.820.7780.0, resuming any WSL-hosted thread fails with:

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

Root cause (verified via app-server JSON-RPC reproduction)

The app sends thread/resume with a request-level config containing:

"mcp_servers.codex_app": {"enabled": true}

with no command/url. Codex (both 0.149 and 0.150) rejects any MCP entry without a transport:

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

Notes:

• The entry is assembled in-memory by the app (the codex-app-tools plugin's desktop-mcp.json does contain command: cmd.exe, but the transport fields are lost on the WSL path). Nothing is wrong with the user's config.toml, despite the error message telling the user to "fix config.toml".
• Request-level config replaces any file-level [mcp_servers.codex_app] table, and disabling the plugin does not stop the injection, so there is no config-level workaround.
• Only the WSL code path produces the transport-less entry.

Workaround

Setting [desktop] runCodexInWindowsSubsystemForLinux = false (the Windows code path always sends a valid entry) — threads resume normally afterwards.

Expected fix

Include command/args in the WSL-path codex_app config, or omit the entry entirely when the transport cannot be resolved.

Trace the WSL path that builds the request-level mcp_servers.codex_app entry, using the app-server JSON-RPC reproduction and codex-app-tools/desktop-mcp.json as starting points. Verify how the transport fields are lost, then confirm completion by resuming WSL-hosted threads without the invalid-transport error while preserving the working Windows path.