I can independently reproduce the issue reported in#40819:
opened 06:42AM - 26 Aug 26 UTC
bug
windows-os
mcp
app
app-server
## Environment
- ChatGPT/Codex desktop app (MS Store, `OpenAI.Codex`), version 2… 6.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:
```json
"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.
My detailed GitHub comment is here:
opened 06:42AM - 26 Aug 26 UTC
bug
windows-os
mcp
app
app-server
## Environment
- ChatGPT/Codex desktop app (MS Store, `OpenAI.Codex`), version 2… 6.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:
```json
"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.
Environment:
Windows 11
WSL2
ChatGPT/Codex Desktop app
Current version: 26.820.7780.0
Previous working version: 26.818.8289.0
WSL mode enabled
The app automatically updated from 26.818.8289.0 to
“failed to load configuration: invalid transport in
The NotebookLM MCP remains configured and working
This appears to be the same WSL integration#40819 . I am waiting
1 Like