[Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works

having the exact same issue

I have the same windows/wsl setup, and am blocked from starting or resuming any of my wsl sessions.

I have the same windows/wsl setup, and am blocked from starting or resuming any of my wsl sessions.

Yes. I was able to revert version and that worked temporarily but of course not the latest up to date version.

exact same issue for me too

Exact the same bug. The good news is that the extension in VS Code works well

same issue

<img width="543" height="120" alt="Image" src="https://github.com/user-attachments/assets/0f561841-9491-47de-a125-81a8cbb3b7d6" />

exactly same issue

I reproduced this on the current Stable package and traced mcp_servers.codex_app to the OpenAI-bundled plugin rather than any user/project MCP configuration.

Reproduced environment

• Windows package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Desktop-bundled CLI: codex-cli 0.150.0-alpha.8
• Desktop app-server platform: Linux under WSL2
• Live app-server distro: Ubuntu-24.04
• Bundled plugin: codex-app-tools@openai-bundled version 0.1.3

The live desktop process reported WSL_DISTRO_NAME=Ubuntu-24.04, platformFamily=unix, and platformOs=linux.

Source of the injected server

The server is contributed by:

$CODEX_HOME/plugins/cache/openai-bundled/codex-app-tools/0.1.3/desktop-mcp.json

Its definition launches a Windows command from the Unix app-server:

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

In this WSL environment, Windows PATH appending is disabled ([interop] appendWindowsPath=false), so cmd.exe is not resolvable by name. The explicit Windows executable remains available through /mnt/c/Windows/System32/cmd.exe. Regardless of whether missing command resolution is the complete cause, the failure occurs during thread/start config loading and is reported as:

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

Isolation results

1. Setting the plugin to enabled = false alone did not stop the bundled MCP contribution from being merged; thread/start still failed with invalid transport.
2. codex plugin remove codex-app-tools@openai-bundled removed the bad contribution and a direct app-server thread/start succeeded.
3. On the next Desktop launch, bundled-plugin reconciliation automatically reinstalled and re-enabled codex-app-tools, and the failure returned.
4. A user-layer valid disabled MCP override makes thread/start succeed even after the bundle is reconciled:

[mcp_servers.codex_app]
command = "/bin/false"
enabled = false

[plugins."codex-app-tools@openai-bundled"]
enabled = false

After config reload, the Desktop log changed from thread/start ... errorCode=-32600 to thread/start ... errorCode=null, followed by Conversation created and a successful turn/start.

Workaround impact

This workaround restores all ordinary chats but removes the five app-self-management tools declared by this bundle:

• automation_update
• create_thread
• send_message_to_thread
• fork_thread
• handoff_thread

Built-in subagents and ordinary coding/MCP/app tools remain available, but workflows that programmatically coordinate persistent Desktop chats or automations lose functionality.

Requested fix

Please make the bundled codex_app transport platform-aware for a Unix/WSL app-server, and ensure that disabling the plugin prevents its MCP contribution from being merged. Bundled reconciliation should also preserve an explicit disabled state rather than restoring a blocking contribution on restart.

Independent repro on the same current Stable Windows package.

Environment:

• Windows package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Desktop-managed WSL app-server: codex-cli 0.150.0-alpha.8
• WSL distro reported by the live app-server: Ubuntu
• Separate standalone WSL Codex CLI: 0.144.6

Observed behavior:

• Creating a new local WSL chat repeatedly fails with invalid transport in mcp_servers.codex_app.
• The user WSL config parses successfully and reports mcp servers: 0.
• The Windows-side Codex config has no codex_app / codex_apps entry.
• Its only configured MCP server is node_repl, which has a valid command + args; the Desktop-managed binary parses it successfully with codex mcp list and shows it enabled.
• The running Desktop app-server is the Windows-app-managed binary under the Windows .codex/bin/wsl/... path, not the standalone WSL CLI.

This independently supports the report that codex_app is being injected by the Desktop/bundled layer rather than coming from user/project TOML. I did not modify config or caches during diagnosis.

[mcp_servers.codex_app] command = "/bin/false" enabled = false [plugins."codex-app-tools@openai-bundled"] enabled = false

This brought it back.
Many thanks @future3OOO

Also hit this issue just after upgrading and the workaround from future3OOO also worked for me.

<img width="827" height="256" alt="Image" src="https://github.com/user-attachments/assets/cf587456-6129-4016-b79b-203eac539e4c" />

Exact same error for me from ChatGPT App after today's update. The workaround worked for me as well.

Same issue: #40732

Same bug, independently reproduced on a second machine: Windows 11 x64, WSL2 Ubuntu,
ChatGPT Stable 26.820.60940 (MSIX 26.820.7780.0), agent environment = WSL.
Every thread/start and thread/resume fails; new and old chats alike. Windows-native mode works.

Additional evidence from the desktop logs (attached):

• thread/start fails with {"code":-32600,"message":"failed to load configuration: invalid transport\nin mcp_servers.codex_app"}, failureReason=invalid_config
• The spawned WSL app-server (0.150.0-alpha.8, coreRuntimeInUse=false) logs:

ignoring invalid experimental feature enablement keys: apps_mcp_path_override
— while the renderer enables apps_mcp_path_override, enable_mcp_apps, apps

• bundled_executable_relocation_failed: source

...WindowsApps\OpenAI.Codex_26.820.7780.0_x64__...\app\resources\codex-resources\bwrap
does not exist (ENOENT at stat_source)

• The selected codex-primary-runtime bundle (26.819.11345) includes a linux-x86_64

artifact, but it is not used for the WSL app-server

Also tried, no effect: deleting .codex\bin\wsl cache (re-provisions the same binary),
Settings → Repair (completes successfully), website installer (same build),
disabling codex-app-tools@openai-bundled. No codex_app/codex_apps entry exists in
any config layer on either the Windows or WSL side (recursive grep).

codex-desktop-40fd35a2-7872-4664-aa55-519c9180b809-37868-t0-i1-215614-0.log
codex-desktop-fb1cceb1-f589-4cae-9335-7eb1f559aad6-23452-t0-i1-213523-0.log

Confirmed on the same Windows/WSL combination:

• ChatGPT/Codex Desktop: 26.820.60940
• MSIX package: OpenAI.Codex 26.820.7780.0
• Desktop-managed WSL CLI: 0.150.0-alpha.8
• codex-app-tools: 0.1.3

The user-layer disabled MCP override also fixed the issue for me:

[mcp_servers.codex_app]
command = "/bin/false"
enabled = false

[plugins."codex-app-tools@openai-bundled"]
enabled = false

After fully quitting and restarting the Desktop app, existing WSL threads resumed successfully. I kept the current 0.150.0-alpha.8 CLI and the original thread/session metadata.

Additional isolation notes:

• Disabling only the plugin was insufficient.
• Renaming/removing desktop-mcp.json was insufficient because Desktop still treated the bundled plugin as installed/current and merged the cached contribution.
• Downgrading the CLI introduced unrelated config/session-schema incompatibilities and was not necessary.
• Restoring the original manifests plus the valid disabled user-layer override above was sufficient.

This supports the conclusion that the invalid codex_app transport is injected by the Desktop/bundled-plugin layer rather than originating in the user-authored MCP configuration.

Can confirm myself, the fix from @future3OOO seemed to partially work at least loading the threads, but with severly reduced functionality.

I can confirm that the user-layer override fixes the original
invalid transport in mcp_servers.codex_app failure on my Windows/WSL setup,
but in my case the recovery is only partial.

Environment:

• ChatGPT/Codex Desktop: 26.820.60940
• MSIX: OpenAI.Codex 26.820.7780.0
• Windows 11 x64
• Agent environment: WSL / Ubuntu-24.04
• Desktop-managed WSL CLI: 0.150.0-alpha.8

Workaround applied:

[mcp_servers.codex_app]
command = "/bin/false"
enabled = false

[plugins."codex-app-tools@openai-bundled"]
enabled = false

This successfully changes existing local thread resume from:

thread/resume ... errorCode=-32600
failed to load configuration: invalid transport
in mcp_servers.codex_app

to:

thread/resume ... errorCode=null

However, all existing local threads I tested remain unable to accept a new
message after resume.

The Desktop log shows the following contradictory state on multiple unrelated
existing local threads:

maybe_resume_success
latestTurnStatus=completed
markedStreaming=true

The thread history renders correctly and thread/resume succeeds, but the
composer Send button remains disabled/grey even when text is entered.

Controls:

Brand-new local chats have a normal enabled Send button.
Existing local threads are affected across multiple unrelated projects.
This reproduces for both WSL-native project paths and Windows-backed local
project paths.
An SSH/remote-hosted existing thread remains usable.
Removing references/attachments from the composer does not change the result.
Entering a single plain-text character still leaves Send disabled.
Switching threads and returning clears a temporary spinner but does not
re-enable Send.

This therefore looks like a second-stage Desktop resume/renderer state problem
after the codex_app transport failure has been bypassed:

thread/resume succeeds
latest turn is completed
Desktop marks conversation streaming
composer remains disabled

This appears closely related to #34026
(completed/idle Windows Desktop threads remaining visually active and unable
to start follow-up turns).

I have not modified the thread/session metadata or SQLite state, and the
existing conversation history remains intact.

So for me the workaround restores thread loading, but does not fully restore
the ability to continue existing local threads.

Same issue. Codex Desktop with WSL is broken for me

Confirming another independent reproduction of this exact regression:

• ChatGPT/Codex Desktop: 26.820.60940
• Windows host with the agent environment set to WSL / Ubuntu
• Project is located in the WSL Linux filesystem
• New chats and existing threads fail with invalid transport in mcp_servers.codex_app
• Switching the agent environment to Windows-native makes the error disappear immediately; switching back to WSL reproduces it
• The WSL user config only contains the project trust entry, and no inspected user/project config contains mcp_servers.codex_app
• Simplifying config.toml and setting [plugins."codex-app-tools@openai-bundled"] enabled = false did not help
• The failure began immediately after the desktop update; no newer update or rollback option is available in the app

The localized Danish UI reports the same underlying error. This strongly confirms that mcp_servers.codex_app is injected by the updated desktop/WSL integration rather than coming from the user's TOML configuration.

having the exact same issue

Working Windows + WSL workaround found — codex_app remains functional

I reproduced the invalid transport in mcp_servers.codex_app failure deterministically on the affected Windows + WSL Desktop path and found a working workaround that restores the original Codex Desktop without disabling codex_app, without /bin/false, and without modifying app.asar.

Tested setup

• Codex Desktop: 26.820.60940
• MSIX: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Desktop-managed WSL CLI: 0.150.0-alpha.8
• bundled codex-app-tools: 0.1.3
• Ubuntu under WSL

Decisive finding

The affected Desktop uses:

mcp_servers.codex_app.enabled_tools

Direct app-server / thread/resume testing showed:

dotted leaf, no base transport       -> INVALID_TRANSPORT
dotted leaf + valid startup base     -> THREAD_OK
nested leaf + valid startup base     -> INVALID_TRANSPORT
dotted full runtime config           -> THREAD_OK
nested full runtime config           -> THREAD_OK

The Desktop-style dotted leaf therefore merges correctly when a valid codex_app base transport already exists.

Root-cause evidence strongly indicates that, on this affected build/path, the local WSL launch path does not materialize the complete getConfigOverrides()-provided codex_app base before spawning the WSL CLI. This is evidence from the observed behavior and static analysis, not a claim about OpenAI's intended internal architecture.

Working workaround

[mcp_servers.codex_app]

command = "/mnt/c/Windows/System32/cmd.exe"

args = [
  "/d", "/s", "/c", "call",
  "./scripts/launch_codex_app_tools_mcp.cmd",
  "./server.mjs"
]

cwd = "/mnt/c/Users/<USER>/.codex/plugins/cache/openai-bundled/codex-app-tools/0.1.3"
enabled = true
startup_timeout_sec = 10
tool_timeout_sec = 3600

env = { CODEX_MCP_NODE_PATH = 'C:\Users\<USER>\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe' }

env_vars = ["CODEX_APP_TOOLS_PIPE_PATH"]

The userspace Node was required on this setup because the packaged Node under WindowsApps returned Access denied through the WSL/cmd.exe bridge.

End-to-end validation

After restarting the original Codex Desktop:

• the invalid transport failure disappeared;
• normal Desktop and project/workspace chats worked;
• codex_app remained functional;
• all five Codex app tools were exposed:
• automation_update
• create_thread
• send_message_to_thread
• fork_thread
• handoff_thread
• a real create_thread invocation succeeded with hostId: local;
• the child chat was created successfully.

I also confirmed that applying:

mcp_servers.codex_app.enabled_tools=["automation_update"]

preserves stdio transport, command, and cwd when the base exists.

The reproduction package is already public here:

https://github.com/AetheraSoftware/aethera-codex-40715-wsl-workaround

Evidence screenshot of the successful real create_thread call:

https://github.com/AetheraSoftware/aethera-codex-40715-wsl-workaround/blob/main/evidence/create-thread-success.png

Alexsander Oliveira
Founder & Technical Director
Aethera Engenharia & Software
GitHub: @AetheraSoftware
Brazil

I can confirm the workaround works for me as well.

Environment:

• Windows + WSL
• Codex Desktop / ChatGPT Stable 26.820.60940

I added the following to my user config:

[mcp_servers.codex_app]
command = "/bin/false"
enabled = false

[plugins."codex-app-tools@openai-bundled"]
enabled = false

After fully quitting and restarting Codex Desktop:

• New conversations can be created successfully again.
• Existing conversations can be opened and viewed normally.
• The previous invalid transport in mcp_servers.codex_app error is gone.

Before applying this workaround, both creating new conversations and opening existing conversations failed after updating to 26.820.60940.

I did not modify or remove any existing session/conversation data.

So this workaround appears to resolve the configuration-loading failure on my setup as well.

Only after switching the runtime environment to Windows can it continue to run

🛠️ How to Fix: invalid transport in mcp_servers.codex_app

If you encounter the error invalid transport in mcp_servers.codex_app, it means the [mcp_servers.codex_app] section is either missing or incorrectly configured in your config.toml file.

Here is how to locate the file and fix the configuration:

1. Locate your config.toml file

Open the configuration file based on your operating system:

• Windows: C:\Users\<Your-Username>\.codex\config.toml
• macOS / Linux: ~/.codex/config.toml

2. Fix the Configuration

Open the file in a text editor (like Notepad, VS Code, or Vim), scroll to the bottom, and append the missing block:

[mcp_servers.codex_app]
transport = "stdio"
command = 'C:\Users\YOUR_USERNAME\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe'
args = ["mcp"]
startup_timeout_sec = 120

⚠️ Note: Make sure to replace YOUR_USERNAME in the command path with your actual Windows username.

3. Save and Restart

Save the file and completely restart your client to apply the fix.

Additional independent reproduction on Windows-native, not WSL. This suggests the failure is not limited to WSL command resolution or the WSL app-server bundle.

Environment

• Codex Desktop: 26.820.60940
• MSIX package: OpenAI.Codex_26.820.7780.0_x64
• Windows 11 x64
• Agent environment: Windows-native
• OpenAI-bundled plugin: codex-app-tools 0.1.3
• Shared WebSocket app-server: global codex-cli 0.149.1, externally started on localhost

Request-level isolation

I placed a temporary local WebSocket proxy between Desktop and app-server and captured only the structure of the affected thread/resume request, with environment values redacted.

Desktop sent a per-thread config containing:

mcp_servers.codex_app.enabled_tools = [...]

but it did not include a base mcp_servers.codex_app definition with command or url. The app-server had also been started without a Desktop-generated codex_app base override. The merged table therefore contained only enabled_tools, and thread/resume failed with:

errorCode=-32600
failed to load configuration: invalid transport
in `mcp_servers.codex_app`

The user-authored TOML parsed successfully and originally contained no codex_app table.

A/B results

1. A direct thread/resume for the same thread with config: null succeeded.
2. A direct resume with pluginsMcp: { productSku: "codex" } and no partial codex_app leaf override also succeeded.
3. Replaying the Desktop-shaped request with only mcp_servers.codex_app.enabled_tools reproduced invalid transport.
4. Adding a valid disabled base definition for mcp_servers.codex_app made the exact Desktop request succeed:

[mcp_servers.codex_app]
command = "cmd.exe"
args = ["/d", "/s", "/c", "call", "./scripts/launch_codex_app_tools_mcp.cmd", "./server.mjs"]
cwd = "<codex-app-tools-0.1.3-cache-directory>"
enabled = false

After a full Desktop/app-server restart, the Desktop log changed to:

thread/resume ... errorCode=null
thread/turns/list ... errorCode=null
thread/items/list ... errorCode=null
maybe_resume_success

1. Disabling features.plugins or setting the bundled plugin to enabled = false did not stop Desktop from sending the partial mcp_servers.codex_app.enabled_tools override.
2. The same failure remained when testing the Desktop-bundled 0.150.0-alpha.8; switching app-server versions alone was insufficient. A complete base table parsed successfully on both tested versions.

Likely failure mode

Desktop appears to emit a leaf override for mcp_servers.codex_app.enabled_tools while assuming that the app-server process already received the corresponding base MCP definition at startup. When Desktop connects to an externally started/shared app-server without that injected base definition, the resulting table has no inferable transport.

The UI then misleadingly tells the user to fix config.toml, even though the invalid partial table is generated by the Desktop request layer.

Expected behavior: Desktop should either include/ensure the complete codex_app base definition before sending enabled_tools, or omit the leaf override and degrade gracefully when that base definition is unavailable.

The disabled-base workaround restores thread loading but intentionally removes the app-self-management MCP tools, so it is not a complete product fix.

having the exact same issue

解决方案 / Solution

已在 Desktop 26.820.60940（MSIX 26.820.7780.0，内置 CLI 0.150.0-alpha.8）的 Windows + WSL 环境验证：旧 Thread 可恢复，新 Thread 可创建，codex-app-tools 的五个工具全部保留。操作前请退出 Desktop，并备份 Windows 侧实际使用的 %CODEX_HOME%\config.toml。

Verified on Desktop 26.820.60940 (MSIX 26.820.7780.0, bundled CLI 0.150.0-alpha.8) with Windows + WSL: existing threads resume, new threads start, and all five codex-app-tools tools remain available. Quit Desktop and back up the Windows-side %CODEX_HOME%\config.toml first.

在 Windows PowerShell 中将动态 pipe 变量转发到 WSL。下面的脚本会保留已有 WSLENV 项；/u 表示 Windows → WSL。

Forward the dynamic pipe variable into WSL from Windows PowerShell. This preserves existing WSLENV entries; /u means Windows → WSL.

$p = @([Environment]::GetEnvironmentVariable("WSLENV", "User") -split ":" | Where-Object { $_ })
if ($p -notcontains "CODEX_APP_TOOLS_PIPE_PATH/u") { $p += "CODEX_APP_TOOLS_PIPE_PATH/u" }
[Environment]::SetEnvironmentVariable("WSLENV", ($p -join ":"), "User")

将下列配置加入 Windows Desktop 使用的 config.toml。把 <WINDOWS_USER> 替换为 Windows 用户名；若 CODEX_HOME 不在默认位置，则改用实际的 Windows 绝对路径。先确认该目录内存在 server.mjs 和 scripts\launch_codex_app_tools_mcp.cmd。

Add the following to the config.toml used by Windows Desktop. Replace <WINDOWS_USER> with the Windows user name; if CODEX_HOME is not in its default location, use its actual Windows absolute path. First confirm that the directory contains server.mjs and scripts\launch_codex_app_tools_mcp.cmd.

[mcp_servers.codex_app]
command = "cmd.exe"
args = [
    "/d", "/s", "/c", "call",
    'C:\Users\<WINDOWS_USER>\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\codex-app-tools\scripts\launch_codex_app_tools_mcp.cmd',
    'C:\Users\<WINDOWS_USER>\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\codex-app-tools\server.mjs',
]
enabled = true
default_tools_approval_mode = "approve"
env_vars = ["CODEX_APP_TOOLS_PIPE_PATH", "CODEX_MCP_NODE_PATH", "CODEX_BROWSER_USE_NODE_PATH", "CODEX_ELECTRON_RESOURCES_PATH", "CODEX_CLI_PATH", "XDG_CACHE_HOME", "HOME", "USERPROFILE", "LOCALAPPDATA", "PATH"]
startup_timeout_sec = 10
tool_timeout_sec = 3600
omit_tools_from = ["deferred", "code_mode"]

[mcp_servers.codex_app.tools]
automation_update = { approval_mode = "prompt" }
create_thread = { approval_mode = "prompt" }
send_message_to_thread = { approval_mode = "prompt" }
fork_thread = { approval_mode = "prompt" }
handoff_thread = { approval_mode = "prompt" }

完全重启 Desktop。我的日志从 thread/resume ... errorCode=-32600 变为 errorCode=null，随后出现 maybe_resume_success；mcpServerStatus/list 同样返回 errorCode=null。launcher 可通过 LOCALAPPDATA 自动找到 Codex 自带 Node，无需固定 runtime hash。

Restart Desktop completely. My log changed from thread/resume ... errorCode=-32600 to errorCode=null, followed by maybe_resume_success; mcpServerStatus/list also returned errorCode=null. The launcher finds Codex's bundled Node through LOCALAPPDATA, so no runtime hash needs to be pinned.

技术分析 / Technical analysis

报错并非来自用户写入的 TOML。Desktop 会合并用户配置、插件清单、启动参数和 Thread 动态配置；mcp_servers.codex_app 来自内置 codex-app-tools，所以即使磁盘文件中没有该块，最终配置中仍可能出现它。

The error is not caused by user-authored TOML. Desktop merges user config, plugin manifests, startup overrides, and per-thread dynamic config. mcp_servers.codex_app comes from bundled codex-app-tools, so it can exist in the final configuration even when absent from disk.

在此构建中，WSL 启动逻辑先生成 spawnArgs，随后才把完整的 codex_app -c override 追加到 args；创建进程时却使用 spawnArgs ?? args。旧 spawnArgs 因此丢掉了插件清单中的 command 和 args。Thread 层仍注入 enabled_tools、enabled 或 pipe 等叶子字段，最终得到一个既无 stdio command、也无 HTTP url 的残缺表，于是触发 invalid transport。

In this build, WSL startup materializes spawnArgs before appending the complete codex_app -c override to args; process creation then uses spawnArgs ?? args. The stale spawnArgs therefore drops the manifest's command and args. The thread layer still injects leaf fields such as enabled_tools, enabled, or the pipe, leaving a partial table with neither a stdio command nor an HTTP url, which triggers invalid transport.

该配置补回缺失的静态 transport，Desktop 继续提供每次启动变化的 named pipe，二者深度合并后形成完整 MCP。它运行真实的 server.mjs，不是 /bin/false、空服务或禁用插件。OpenAI 文档也规定本地 stdio MCP 必须包含 command。

The added configuration restores the missing static transport while Desktop continues to provide the per-run named pipe; deep merging produces a complete MCP. It launches the real server.mjs, not /bin/false, an empty server, or a disabled plugin. OpenAI's documentation likewise requires a command for a local stdio MCP.

限制性总结 / Limitations

这是配置层 hotfix，不是上游代码修复。插件升级、cache 清理、自定义 CODEX_HOME 或重装可能改变绝对路径；若 cmd.exe 因 WSL 禁止追加 Windows PATH 而不可解析，可改为 command = "/mnt/c/Windows/System32/cmd.exe"。此方案依赖 WSL interop 和 Windows named pipe。

This is a configuration-level hotfix, not the upstream code fix. Plugin updates, cache cleanup, a custom CODEX_HOME, or reinstalling may change the absolute paths. If cmd.exe is unavailable because WSL does not append Windows PATH, use command = "/mnt/c/Windows/System32/cmd.exe". The solution depends on WSL interop and the Windows named pipe.

官方修复发布后，应删除手动添加的 [mcp_servers.codex_app]，并从用户级 WSLENV 删除 CODEX_APP_TOOLS_PIPE_PATH/u，恢复由 Desktop 管理内置 transport。

After an official fix ships, remove the manual [mcp_servers.codex_app] block and CODEX_APP_TOOLS_PIPE_PATH/u from the user-level WSLENV, returning management of the bundled transport to Desktop.

Same issue with the same windows/wsl setup.

I can independently reproduce the same issue on a separate Windows + WSL environment.

Environment

• ChatGPT / Codex Desktop: 26.820.60940
• Windows AppX package: OpenAI.Codex 26.820.7780.0 x64
• Windows 11 Pro 25H2, build 26200.9168
• WSL: 2.7.12.0
• Ubuntu: 26.04.1 LTS
• WSL kernel: 6.18.33.2-microsoft-standard-WSL2
• Codex CLI: 0.149.1
• Git: 2.53.0

Observed behavior

Codex Desktop works normally with:

• Agent Environment: Windows native

After switching to:

• Agent Environment: Windows Subsystem for Linux
• Integrated terminal: WSL

and restarting the app, every new Codex chat fails before the prompt is executed with:

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

For context regarding my detailed reproduction above (issue comment 5419327488):

Alexsander Oliveira
Technical Director / Senior Programmer
Aethera Engenharia & Software

We are providing these findings to help the OpenAI engineering team isolate the regression. The report intentionally omits company project details and contains only the technical information relevant to reproducing the Codex Desktop failure.

Having the exact same issue now.

26.819.11345 same now

[mcp_servers.codex_app]
command = "cmd.exe"
args = [
    "/d", "/s", "/c", "call",
    'C:\Users\<WINDOWS_USER>\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\codex-app-tools\scripts\launch_codex_app_tools_mcp.cmd',
    'C:\Users\<WINDOWS_USER>\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\codex-app-tools\server.mjs',
]
enabled = true
default_tools_approval_mode = "approve"
env_vars = ["CODEX_APP_TOOLS_PIPE_PATH", "CODEX_MCP_NODE_PATH", "CODEX_BROWSER_USE_NODE_PATH", "CODEX_ELECTRON_RESOURCES_PATH", "CODEX_CLI_PATH", "XDG_CACHE_HOME", "HOME", "USERPROFILE", "LOCALAPPDATA", "PATH"]
startup_timeout_sec = 10
tool_timeout_sec = 3600
omit_tools_from = ["deferred", "code_mode"]

[mcp_servers.codex_app.tools]
automation_update = { approval_mode = "prompt" }
create_thread = { approval_mode = "prompt" }
send_message_to_thread = { approval_mode = "prompt" }
fork_thread = { approval_mode = "prompt" }
handoff_thread = { approval_mode = "prompt" 

this brought it back. But the first word ping became very high now

Independent reproduction on the current Stable Windows + WSL build, with a deterministic parser-level isolation of the failure.

Environment

• Windows package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Desktop-managed WSL CLI: codex-cli 0.150.0-alpha.8
• WSL2: Ubuntu 24.04, kernel 6.18.33.2-microsoft-standard-WSL2
• Bundled plugin: codex-app-tools@openai-bundled 0.1.3
• Desktop agent environment: WSL

Both thread/start and thread/resume fail with:

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

The active Desktop-managed app-server uses the Windows Codex home mounted into WSL. The user config contains no persisted mcp_servers.codex_app table. Setting [plugins."codex-app-tools@openai-bundled"] enabled = false is read by the active app-server but does not stop the failure.

Deterministic isolation

Using the exact Desktop-managed CLI and the same Windows-side CODEX_HOME, a complete inline mcp_servers.codex_app table from desktop-mcp.json parses successfully. Supplying only the leaf that Desktop adds at thread scope reproduces the exact failure in about two seconds:

$ codex -c 'mcp_servers.codex_app.enabled_tools=["automation_update"]' mcp list
Error: failed to load bootstrap configuration

Caused by:
    invalid transport
    in `mcp_servers.codex_app`

Adding a non-empty base command makes that same leaf override parse successfully. This confirms that the failure is an incomplete merged MCP table, not an invalid user-authored TOML file or an unsupported field in desktop-mcp.json.

Packaged Desktop code path

Inspection of the installed app.asar shows a WSL-specific argument propagation bug:

1. The WSL launch helper materializes spawnArgs from the base CLI args.
2. getConfigOverrides() then appends the complete bundled mcp_servers.codex_app={...} override to args.
3. The stdio process launcher uses spawnArgs ?? args.
4. Therefore the WSL process starts from the already-materialized spawnArgs and never receives the late full MCP override.
5. Desktop still supplies the per-thread mcp_servers.codex_app.enabled_tools leaf, leaving a table with neither command nor url; the core parser correctly reports invalid transport.

This also explains why the same manifest parses when passed directly to the CLI and why the regression is concentrated in the Desktop-managed WSL launch path.

Workaround validation

The disabled valid base-table workaround restores configuration loading:

[mcp_servers.codex_app]
command = "/bin/false"
enabled = false

However, that workaround intentionally removes the app self-management tools. A complete functional workaround additionally has to restore the real cmd.exe transport and forward the per-launch CODEX_APP_TOOLS_PIPE_PATH into WSL; this is not equivalent to an upstream fix.

Expected fix: append Desktop-generated config overrides before WSL spawnArgs are materialized, or rebuild spawnArgs after the override is appended. Desktop should also avoid sending the enabled_tools leaf unless a valid base transport is present.

Independent confirmation of the WSL-launch-path theory above, plus extra evidence and a cleaner workaround (codex-cli 0.150.0-alpha.8, desktop 26.820.7780.0 / client_version 26.820.60940, Ubuntu-24.04):

1. Corroborating the getConfigOverrides() ordering bug from the other side

Inspecting the same app.asar: the -c mcp_servers.codex_app=... override builder (Ope() in the minified bundle) starts with:

async function Ope({hostConfig:e, ...}) {
  let r = process.env[Au];
  if (e.kind !== `local` || n.pi(e) || !r) return [];
  ...
  return [`mcp_servers.codex_app=${KT({...s, command: process.platform === `win32` ? s.command : ..., cwd: i.path, enabled: !0, ...})}`]
}

i.e. the full stdio override is only ever built for hostConfig.kind === "local" — under WSL mode the launch helper never gets it, while the per-thread mcp_servers.codex_app.enabled_tools leaf is still sent. The merged table then has neither command nor url, which matches the observed failure exactly. This also explains why Windows-native mode keeps working with the identical manifest.

2. App-server log signature

In ~/.codex/sqlite/logs_2.sqlite each failing request stops dead inside load_with_cli_overrides immediately after the /etc/codex/managed_config.toml not found line — no further logs for that request, error returned to the client. Startup-time config parsing of the same CODEX_HOME is clean (codex mcp list only shows node_repl), confirming this is strictly the per-thread override merge.

3. Parser behavior notes (0.150.0-alpha.8)

For reference, feeding crafted entries to codex mcp list (bootstrap config loader): command-only parses, url-only parses, a table without either is dropped silently, and a table with both command and url throws invalid transport. So the error string can surface from more than one shape; the thread-start layer rejecting the incomplete {enabled_tools} table is what hits desktop users here.

Also worth noting the user-facing error doesn't name the offending server key, which made everyone grep their own config.toml first — appending in mcp_servers.<name> at the throw site would save a lot of time.

4. Workaround that needs no per-project config.toml edits

Instead of adding a fake [mcp_servers.codex_app] base table, removing the injection at the source restores thread creation immediately (validated):

1. $CODEX_HOME/config.toml → [plugins."codex-app-tools@openai-bundled"] enabled = false
2. Rename desktop-mcp.json to something inert in both:

• ~/.codex/plugins/cache/openai-bundled/codex-app-tools/<ver>/
• ~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/codex-app-tools/

The override builder reads that manifest via readFile(join(pluginPath, "desktop-mcp.json")) with an ENOENT→return [] catch, so with the file gone it cleanly sends nothing. Cost: agent-side tools (create_thread, fork_thread, handoff_thread, automation_update, send_message_to_thread) are unavailable until upstream fixes the launch-path ordering.

same issues！

Another update, another error on start. This is gettjng ridiculous.

Independent reproduction and source-path confirmation from a second WSL distribution.

Environment

• ChatGPT/Codex Desktop stable package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Client build: 26.820.60940
• Bundled Linux app-server: codex-cli 0.150.0-alpha.8
• Windows 11 + WSL2 Debian 13
• Repository stored under the WSL filesystem (/home/.../KT)

Runtime evidence

The official WSL ELF copied by Desktop is byte-for-byte identical to the packaged resources/codex (same SHA-256), and initializes successfully:

spawnCommand=wsl.exe
argsCount=4
currentVersion=0.150.0-alpha.8
initialize_handshake_result outcome=success

The failure occurs only when Desktop sends thread/start or thread/resume:

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

In Windows-native mode, the same build starts app-server with argsCount=6; the additional argument pair is a complete -c mcp_servers.codex_app={command,args,cwd,env,...} transport override, and threads work.

All relevant user/system environment overrides are unset, and user/project config files contain no mcp_servers.codex_app table.

Packaged Desktop branch mismatch

The installed bundle shows two incompatible decisions:

1. The main-process WSL branch intentionally skips the full codex_app transport override.
2. The renderer still classifies the WSL-backed host as kind: "local" and writes mcp_servers.codex_app.enabled_tools into every new/resumed thread config.
3. The merged MCP table therefore has enabled_tools but no command or url, which correctly triggers the core parser's invalid transport error.

Relevant packaged locations in this build:

• app.asar/.vite/build/main-TomazcfO.js (full transport override builder)
• app.asar/.vite/build/src-DpTP2OT9.js (WSL host detection/spawn branch)
• app.asar/webview/assets/app-initial-wqR9HoXP.js (per-thread mcp_servers.codex_app.enabled_tools injection)

Regression evidence

Desktop package 26.818.8289.0 used the same four-argument WSL startup shape, but historical logs show successful thread/start and thread/resume. The failure begins after updating to 26.820.7780.0.

Suggested invariant

Only write mcp_servers.codex_app.enabled_tools when the complete codex_app transport was actually injected. For WSL, either:

• omit the MCP entry and use the existing dynamicTools path, or
• provide a complete WSL-compatible transport.

This is not repairable through config.toml; the user-facing prompt to edit that file is misleading for this regression.

Clarification: Codex itself was working successfully in my WSL/Ubuntu workspace. Standalone Codex CLI 0.145.0 worked, and the exact bundled 0.150.0-alpha.8 executable also worked when launched manually against the same WSL workspace. The failure was specific to Codex Desktop Stable 26.820.60940, which generated the invalid mcp_servers.codex_app transport error.

Additional independent reproduction and lifecycle observations

I can independently reproduce this issue on the same stable Windows
desktop release.

Environment

• Windows 11 x64
• WSL2
• Agent environment: Windows Subsystem for Linux
• Windows desktop package: 26.820.7780.0
• Internal client release: 26.820.60940
• Previously working release: approximately 26.609.4994.0

WSL2 is mandatory for my development environment.

Reproduction results

After restoring my original configuration files, the desktop application
itself launches successfully, but both WSL thread operations remain
completely blocked.

1. Starting a new WSL chat

At approximately 2026-08-26 15:58 CST (UTC+8), corresponding to 07:58 UTC,
I created a new chat in a WSL project and sent ping.

The application displayed:

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

The new thread could not start.

2. Resuming a non-pre-warmed WSL thread

At approximately 2026-08-26 15:59 CST (UTC+8), corresponding to 07:59 UTC,
I opened an existing WSL thread that had not been accessed through Remote.
The application displayed:

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.

The historical content could not be displayed.

User configuration check

Neither of these user configuration files contains a

``[mcp_servers.codex_app]`` entry:

C:\Users\<user>\.codex\config.toml
/home/<user>/.codex/config.toml

This is consistent with the other reports that mcp_servers.codex_app
is injected by the desktop application rather than defined in the user's
TOML configuration.

Clean-config isolation result

OpenAI Help Center asked me to temporarily rename both config.toml
files and restart the desktop application.
With both files renamed, the application failed before reaching the
new-thread test:

ChatGPT failed to start.

Failed to spawn Codex CLI at:
C:\Users\<user>\.codex\bin\wsl\bf0dd1e87d338bce\codex

I did not delete or modify the .codex\bin directory. Restoring both
original config.toml files allowed the application to launch again, but
thread/start and thread/resume continued to fail with the original
invalid transport error.

Therefore, removing the user configuration is not a usable workaround in
this environment.

Remote pre-warming observation

There is one potentially useful lifecycle observation:

1. A cold existing WSL thread fails to resume in the Windows desktop app.
2. If I first access that particular thread through Remote in the ChatGPT

mobile app, the Windows desktop app may then open that same thread and
display its history.

1. New WSL chats still fail, and other non-pre-warmed threads still fail.

This appears to be a per-thread warm-session or attachment bypass. It
does not resolve the invalid runtime configuration and is not a general
workaround.

Impact

This is a complete blocker for WSL2 mode:

• thread/start fails for every new WSL chat.
• thread/resume fails for cold existing WSL threads.
• The user-authored configuration contains no mcp_servers.codex_app.
• Remote pre-warming only occasionally makes one specific existing thread

accessible.
I have also reported this through OpenAI Help Center. Screenshots of the
three failure modes are available if useful.

<img width="2109" height="1439" alt="Image" src="https://github.com/user-attachments/assets/444ae39d-3a7b-4bd7-a5ad-ce26530445ab" />
<img width="2118" height="1440" alt="Image" src="https://github.com/user-attachments/assets/a43f6557-6fec-4ccc-aa42-afd6b6888145" />

<img width="579" height="175" alt="Image" src="https://github.com/user-attachments/assets/c2fc53c4-192c-4a7b-b9e7-bef75c5e1aac" />

A Codex bug drained all my tokens.
Codex's cross-directory patching and credential decryption failures caused excessive retries, wasting a large number of tokens.

I can reproduce this on Windows with Codex App 26.820.60940 as well.

Observed error when creating a new chat:

failed to load configuration: invalid transport in mcp_servers.codex_app

I inspected my active user config.toml and there is no [mcp_servers.codex_app] entry. The only MCP server present is [mcp_servers.node_repl] with a valid command/args configuration. The file also contains the app-generated environment entries, including BROWSER_USE_CODEX_APP_VERSION = "26.820.60940" and WSL-related variables.

I also checked CODEX_HOME; it is not explicitly set in the Windows environment.

This appears consistent with the report here: the invalid mcp_servers.codex_app entry seems to be injected/merged by the Desktop app rather than coming from the user's config.toml.

I can confirm the same regression on Windows after updating ChatGPT Desktop to 26.820.60940.

Environment / findings:

• Windows desktop app, Work/Codex configured to run via WSL (runCodexInWindowsSubsystemForLinux = true)
• Bundled CLI: codex-cli 0.150.0-alpha.8
• codex CLI starts normally
• codex mcp list works normally and lists my configured MCP servers (node_repl, pencil, cloudways)
• codex_app is NOT present in my user config.toml / CLI MCP list
• The bundled codex-app-tools plugin has desktop-mcp.json defining codex_app with command: "cmd.exe" and no explicit transport field
• Disabling [plugins."codex-app-tools@openai-bundled"] enabled = false does not change the error
• Clearing/regenerating Codex runtimes and plugin caches does not change the error; regenerated desktop-mcp.json is byte-identical to the previous copy
• Creating a new Work thread still fails with: failed to load configuration: invalid transport in mcp_servers.codex_app

This strongly matches the app-side injection / WSL-path regression described here rather than a user config.toml problem.

I can reproduce the same issue on ChatGPT Plus using the official Codex Desktop app on Windows with WSL2.

I do not use any third-party proxy, reverse proxy, account switcher, or patched Codex client.

My existing WSL threads were working normally immediately before the Desktop update. After updating to the 26.820.x release, reopening the same threads consistently fails with:

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.

So this appears to be a regression introduced by the latest Desktop update.

Reproduced the same Stable-vs-Beta split on Windows 11 + WSL2, and I think I can explain why the Beta is unaffected.

The Beta does not ship the codex-app-tools plugin at all.

Comparing the bundled marketplace each app materialises into ~/.codex/.tmp/bundled-marketplaces/openai-bundled, from the two apps' own desktop logs on the same machine:

Stable 26.820.7780.0 : ["codex-app-tools","sites","computer-use","latex","visualize"]
Beta   26.727.4816.0 : ["sites","browser","chrome","computer-use","latex","visualize"]

The Beta predates the bundling of codex-app-tools, so there is no codex_app MCP server for it to assemble and inject at thread start. Its log contains zero references to a codex_app MCP entry — the only matches for that substring are the module name codex_app_server in an unrelated warning. So this is not the Beta constructing a valid entry where Stable constructs an invalid one; it constructs no entry at all.

That also fits your isolation results: the bundled 0.150.0-alpha.8 binary is fine standalone, because nothing injects the transport-less table into it.

The Beta is genuinely using the WSL path, so this is not a "Beta silently falls back to Windows-native" artefact. With [desktop] runCodexInWindowsSubsystemForLinux = true unchanged, it spawns via wsl.exe -d Ubuntu, stages its own WSL agent at ~/.codex/bin/wsl/<hash>/codex, and reports app-server 0.146.0-alpha.9.2. Measured over one session:

| | Stable 26.820.7780.0 | Beta 26.727.4816.0 |
|---|---|---|
| invalid transport | 20 | 0 |
| thread/resume | 18 of 18 failed | 39 of 39 OK |
| thread/start | all failed | 5 of 5 OK |

Two practical caveats for anyone using the Beta as a stopgap

1. Because the Beta lacks codex-app-tools, the app tools it provides are also gone — create_thread, send_message_to_thread, fork_thread, handoff_thread, automation_update. In-app automations that depend on those will not run there.
2. The Beta shares CODEX_HOME with Stable and writes to it. On first launch it rewrote the notify entry in config.toml to point at its own older cua_node runtime hash, and re-materialised the bundled marketplace with its older plugin set — after which the loader warns configured non-curated plugin no longer exists in discovered marketplaces during cache refresh for several plugins that only exist in the newer bundle (presentations, spreadsheets, template-creator, visualize, sites). Worth taking a copy of config.toml before switching.

---

This comment was written by Claude (Anthropic's Claude Code) and posted with my explicit permission, summarising a debugging session Claude ran on the affected machine. Every measurement above was executed and verified there.

I can confirm the same issue on Windows after updating ChatGPT Desktop to 26.820.60940.

why I even update my codex in the middle of my work. Silly me

Additional confirmed reproduction on Aug 26, 2026:

• ChatGPT/Codex Stable build: 26.820.60940 (Windows MSIX 26.820.7780.0)
• Subscription: Pro
• Host: Windows 11 with the Codex agent configured to run in WSL2
• Impact: complete work blocker; neither new chats nor existing chats can start/resume
• Error: failed to load configuration: invalid transport in mcp_servers.codex_app

Verified both the Windows user config and the WSL user config. Neither contains [mcp_servers.codex_app] nor [mcp_servers.codex_apps]. The configured user MCP servers have valid command or url transports. Disabling all installed plugins, including codex-app-tools, does not change the error.

This began immediately after the Stable update. The evidence strongly matches the issue description: the invalid codex_app configuration is being injected/generated by Desktop Stable, rather than loaded from user TOML.

Please prioritize a Stable hotfix or publish an official rollback procedure. This currently prevents paid users with WSL development environments from using the desktop app at all.

I started the codex cli from wsl and asked it to fix the problem with windows desktop codex application. Of course it did (using my own tokens). this is its final answer:

Fixed the Windows Codex config at /mnt/c/Users/{myuser}/.codex/config.toml:192. What changed: - Added a clean [mcp_servers.codex_app] entry. - Did not include any transport key. - Created backup: /mnt/c/Users/{myuser}/.codex/config.toml.bak-20260826100651. Verification: - Ran the installed Windows Codex CLI config loader with codex.exe mcp list. - It now loads successfully and lists codex_app, node_repl, and openaiDeveloperDocs. Next step: fully close/reopen the Codex desktop app on Windows, then reopen the thread that was failing.

I asked then a RCA and a workaround to put in the comment here, this is what it replied:

## Diagnostic / workaround for config.toml: invalid transport in mcp_servers.codex_app

### Symptom

After the latest Codex desktop update on Windows, existing project threads fail to resume with:

> 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.

### What I found

On my machine, the active Windows config was:

C:\Users\{myuser}\.codex\config.toml

The visible TOML did not contain a [mcp_servers.codex_app] block or any transport = ... setting. It only had
node_repl and openaiDeveloperDocs.

The bundled Codex app tools plugin did contain a generated MCP definition here:

C:\Users\{myuser}\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\codex-app-tools\desktop-mcp.json
misreading or migrating the generated codex_app MCP server shape and failing schema validation on transport.

### Workaround

Add an explicit command-based codex_app MCP server block to config.toml, without any transport key.

PowerShell:

```powershell
$Config = "$env:USERPROFILE\.codex\config.toml"
$PluginDir = "$env:USERPROFILE\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\codex-app-tools"
$Backup = "$Config.bak-$(Get-Date -Format yyyyMMddHHmmss)"

Copy-Item $Config $Backup

@"

[mcp_servers.codex_app]
command = "cmd.exe"
args = ["/d", "/s", "/c", "call", "./scripts/launch_codex_app_tools_mcp.cmd", "./server.mjs"]
cwd = '$PluginDir'
startup_timeout_sec = 10
tool_timeout_sec = 3600
"@ | Add-Content -Path $Config

  Important: cwd should be a TOML literal string with single quotes. Windows backslashes inside double quotes can break
  TOML parsing, for example C:\Users is interpreted as an invalid escape.

  ### Verification

  Run:
PowerShell:

  ```powershell
  $CodexExe = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin\*\codex.exe" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1 -ExpandProperty FullName

  & $CodexExe mcp list

Expected result: codex_app appears in the MCP server list and the command exits successfully.

After that, fully close and reopen Codex Desktop, then reopen the affected thread.

### Dev-team lead

This looks like a regression in the Windows desktop resume/config bootstrap path around the bundled codex-app-tools
MCP server. A generated/plugin-provided codex_app server appears to be validated as if it had an unsupported or stale
transport value. A robust fix would either normalize the generated desktop-mcp.json server shape before validation or
ignore/remove stale transport fields for command-based MCP servers during config/thread resume.

Same issue on Windows + WSL.

Feedback ID: 01a03d1c-5b83-7ea0-ab04-e43b287f32fd

Environment:

• Windows package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• WSL distro: Ubuntu
• WSL version: 2.7.12.0

Windows Native agent works. WSL agent fails for both new chats and resumed chats with:

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

I can confirm the same regression on Windows 11 + WSL2 with Codex Desktop 26.820.x. Both creating new chats and resuming existing chats fail with invalid transport in mcp_servers.codex_app, while my user config.toml has no mcp_servers.codex_app entry. WSL is my required development environment, so switching the agent to Windows-native is not a viable workaround for me. This is a complete work blocker.

Given that this regression completely blocks a supported development workflow for paying users, OpenAI should also consider compensation for affected accounts. At minimum, users impacted by the WSL outage should receive additional/banked usage resets (or equivalent credits) for the period in which Codex Desktop was unusable in their required environment. We are paying for access to this service, and a release regression that prevents all new/resumed WSL chats from working should not consume users' paid usage window without remedy.

@taobaibais
You can download an earlier version of Codex on Uptodown .com. I uninstalled the app, downloaded a version from Aug 21 and I'm good to go. I also had to get my Claude Code to scan my Codex's config.toml and clean a few conflicting things.

Silly me for updating while I was working...

i also met this error, but i use the config to open it, maybe have some hidden problem .

[mcp_servers.codex_app]
command = ""
enabled = false

At this point this regression has multiple duplicate reports, dozens of independent confirmations/reactions, and a reproducible failure mode that completely blocks Codex Desktop for users who require WSL. Could someone from OpenAI please at least acknowledge the incident publicly and confirm that it has been triaged? Even without an ETA, a brief status update would help affected paying users understand whether a fix or rollback is being worked on.

having the exact same issue

Formal customer escalation: this regression has now been publicly reproducible for many hours, has accumulated dozens of independent confirmations and reactions, and completely blocks Codex Desktop for paying users who require WSL. At the same time, there is still no public acknowledgement from OpenAI, no visible assignee, no rollback guidance, and no status on a hotfix.

That level of silence is not an acceptable way to handle a release regression that makes a paid development workflow unusable. Affected users should not have to reverse-engineer internal MCP injection, experiment with unsupported config edits, or rely on third-party rollback sources just to keep working.

Please provide, at minimum:

1. a public acknowledgement that the incident is known and triaged;
2. a short status on whether a hotfix or rollback is being worked on;
3. official guidance for affected WSL users that does not require unsupported hacks;
4. a statement on compensation for paying users whose Codex access was effectively unusable in their required environment — e.g. banked/additional usage resets or equivalent credits.

This does not require an ETA. It does require basic communication with affected customers.

Same issue here. For now I managed to use the IDE plugin connected to codex, but this issue needs to be resolved ASAP

exact same issue

The official OpenAI status page is still reporting “We’re fully operational” and “We’re not aware of any issues affecting our systems”, including Codex, while this regression is clearly and repeatedly blocking Windows + WSL2 Codex Desktop users after the current Stable release.

At this point there are dozens of confirmations, many duplicate reports, and a reproducible failure mode tied to the Desktop → WSL launch path. For affected users this is not a minor degradation: creating new WSL chats and resuming existing WSL chats can be completely unavailable.

Could OpenAI please clarify why this incident is not reflected on the public status page, or at least post a scoped Codex Desktop / Windows + WSL incident there if aggregate availability remains otherwise healthy?

A status page can stay green for the overall service while still acknowledging a major product-surface outage affecting a specific supported environment. Right now affected paying users see both the GitHub issues go unanswered and the official status page say everything is operational, which is a very confusing incident-response experience.

Please provide at minimum:

• a public acknowledgement that this Windows + WSL regression is known and triaged;
• a scoped status-page notice or explanation for why one is not being posted;
• current guidance on hotfix/rollback/official workaround status;
• and a response on compensation for affected paid users whose required Codex workflow has been unavailable.

Independent confirmation and WSL-native workaround

I independently reproduced and isolated this on:

• Codex Desktop client 26.820.60940
• Windows package 26.820.7780.0
• Desktop-managed WSL CLI 0.150.0-alpha.8
• codex-app-tools@openai-bundled 0.1.3

The user configuration contained no mcp_servers.codex_app table and no transport key. A full Desktop restart and an account re-login did not change the failure.

Deterministic request-level confirmation

Using the exact bundled WSL app-server and a sanitized copy of an affected rollout:

1. thread/resume with Desktop's flat override below reproduced -32600 / invalid transport:

``json
{
"config": {
"mcp_servers.codex_app.enabled_tools": ["x"]
}
}
``

1. The same resume without that leaf override succeeded.
2. The same resume with the leaf override and a complete user-level codex_app stdio definition succeeded.
3. The bundled CLI then resolved codex_app as transport.type = "stdio".

This confirms the root cause described in #40894: Desktop sends a per-thread leaf while the WSL app-server did not receive the corresponding base transport. The resulting merged table has neither command nor url. The UI's instruction to repair user-authored TOML is therefore misleading.

WSL-native workaround

The disabled /bin/false workaround restores ordinary chats but intentionally removes the app self-management tools. The following alternative supplies the actual bundled Unix launcher instead. It does not require a versioned plugin-cache path or a user-level WSLENV change.

Quit Desktop completely and back up the Windows-side %CODEX_HOME%\config.toml first. Replace <WINDOWS_USER> or the whole cwd value when using a non-default CODEX_HOME.

[mcp_servers.codex_app]
command = "/bin/sh"
args = [
    "./scripts/launch_codex_app_tools_mcp",
    "./server.mjs",
]
cwd = "/mnt/c/Users/<WINDOWS_USER>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/codex-app-tools"
env_vars = [
    "CODEX_APP_TOOLS_PIPE_PATH",
    "CODEX_MCP_NODE_PATH",
    "CODEX_BROWSER_USE_NODE_PATH",
    "CODEX_ELECTRON_RESOURCES_PATH",
    "CODEX_CLI_PATH",
    "XDG_CACHE_HOME",
    "HOME",
    "USERPROFILE",
    "LOCALAPPDATA",
    "PATH",
]
enabled = true
startup_timeout_sec = 10
tool_timeout_sec = 3600
default_tools_approval_mode = "approve"

[mcp_servers.codex_app.tools.automation_update]
approval_mode = "prompt"

[mcp_servers.codex_app.tools.create_thread]
approval_mode = "prompt"

[mcp_servers.codex_app.tools.send_message_to_thread]
approval_mode = "prompt"

[mcp_servers.codex_app.tools.fork_thread]
approval_mode = "prompt"

[mcp_servers.codex_app.tools.handoff_thread]
approval_mode = "prompt"

Before reopening Desktop, I validated the resulting TOML with the bundled CLI and replayed the exact previously failing thread/resume request successfully. This config points at the real server.mjs rather than disabling the server. End-to-end app-tool invocation still depends on Desktop providing a valid per-launch pipe.

This remains a temporary config-level workaround. The upstream fix should ensure the complete platform-appropriate base transport reaches the WSL process before Desktop sends any mcp_servers.codex_app.* leaf overrides. The manual block should be removed after that fix ships.

Thanks for the bug report. We understand the problem and are working on expediting a fix.

@etraut-openai — since your acknowledgement, I completed the Windows + WSL investigation and updated my earlier technical comment with end-to-end validation.

The key result is a workaround that restores the affected Codex Desktop while preserving all five built-in codex_app tools — without /bin/false and without modifying app.asar. A real create_thread invocation also succeeded with hostId: local. I published the decisive config/merge matrix and the sanitized reproduction package as well.

Technical comment: https://github.com/openai/codex/issues/40715#issuecomment-5419327488

Reproduction package: https://github.com/AetheraSoftware/aethera-codex-40715-wsl-workaround

Sharing this only in case it helps shorten the upstream investigation/fix. Happy to provide any additional sanitized test evidence if useful.

Is there a way to install or downgrade the version?

Version 26.820.71523 just rolled out. I updated from 26.820.60940 and can confirm that the invalid transport in mcp_servers.codex_app issue now appears to be fixed.

The same WSL project and configuration that previously failed are loading normally again.

Version 26.820.71523 just rolled out. I updated from 26.820.60940 and can confirm that the issue now appears to be fixed.invalid transport in mcp_servers.codex_app The same WSL project and configuration that previously failed are loading normally again.

I think so. I just installed the official update, and the project is loading normally now.

I agree, I received the update and it appears to be resolved now.

I can confirm that the regression reported here is no longer reproducible in the following environment:

• Codex Desktop: 26.820.71523
• Microsoft Store package: OpenAI.Codex_26.820.9563.0_arm64__2p2nqsd0c76g0
• Windows 11 ARM64
• WSL2 / Ubuntu

Both of the affected workflows now succeed:

• Creating a new task using the WSL agent environment
• Resuming an existing WSL task

The invalid transport in mcp_servers.codex_app error no longer appears. I have not added a user-level mcp_servers.codex_app override or applied any of the configuration workarounds discussed in this issue.

Yes can confirm myself. Using 26.820.71523 I am able to load threads just fine. Thank you Codex team!

etraut-openai — It's still broken for me and I'm on today's latest version 26.820.71523. I see other comments above that it's working, but definitely not for me.