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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #40715
• #40732

Powered by Codex Action

same issue here

Same issue. Windows + WSL2 + codex desktop. is there any workaround without having to install another version of codex desktop

Codex Desktop WSL thread/start injects partial mcp_servers.codex_app.enabled_tools without a transport, causing invalid transport in bundled app-server 0.150.0-alpha.8

Same issue, Windows 11 + WSL2 OpenSUSE Tumbleweed.

same issue here.

windows 11, WSL2, codex app.

same issue here. windows 11+WSL2

I can reproduce this exact issue on Windows 11 + WSL2 with Codex Desktop 26.820.60940 and:

[desktop]
runCodexInWindowsSubsystemForLinux = true

The error is:

invalid transport in mcp_servers.codex_app

I verified that there is no [mcp_servers.codex_app] entry in my user, WSL, project, or /etc/codex config.toml files.

I also traced codex_app to the bundled plugin:

~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/codex-app-tools/desktop-mcp.json

and that file contains a valid transport:

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

So the source configuration itself appears valid. This is consistent with the report that the Desktop → WSL path is dropping the transport fields when constructing the request-level mcp_servers.codex_app configuration.

This started immediately after the 26.820.x update; the same setup was working before the update.

Also reproducible on app version 26.820.60940 (not MS Store), Windows NT 10.0.26200.0 x64,
same WSL agent mode. Confirmed the same workaround (Agent environment → Windows native)
resolves it.

Same issue on my end, Windows 11 + WSL2 running Ubuntu 24.04 using the Codex Desktop App. It all worked fine yesterday, updated before going to sleep and now can't resume because of this error.

This keeps happening. It's the third or fourth time they introduce breaking changes for the WSL subsystem with an update.
Please test these better. I know, mistakes happen, but this error would have been caught by simply trying to resume or start a new thread, which indicates no testing had been done.

Same

<img width="387" height="109" alt="Image" src="https://github.com/user-attachments/assets/84d43a70-290e-47eb-8b16-b16278abeab6" />

Same issue here.
Since updating this morning, I’ve been getting pop-up messages saying that it’s unavailable. At first, I didn’t realize that the problem was with Codex because the error message was very misleading. It took me an hour to discover that changing the configuration wouldn’t solve the problem.
As a temporary workaround, you can try the solution described in issue #40715. If you don’t want to modify the configuration, it seems that the only option is to roll back to a previous version of the Codex desktop app.

---

Additional investigation (AI-assisted analysis based on public source code, 2026-08-26)

I asked GPT to further inspect the public openai/codex source code, the bundled plugin manifest documented in #40715, and the app-server's JSON-RPC behavior.

The specific code that constructs the Desktop request and performs bundled-plugin reconciliation is not public. The sections below therefore explicitly distinguish between "runtime facts that are already confirmed" and "implementation hypotheses that require maintainer verification."

Behavior that can be confirmed from the public runtime

1. thread/start and thread/resume both accept request-level configuration overrides. The app-server first converts the request's config object into a TOML override layer and then loads the final configuration.

1. The public MCP configuration parser requires every MCP server to have a transport:

• When command is present, it is parsed as a stdio transport;
• when url is present, it is parsed as a streamable HTTP transport;
• when neither is present, it immediately returns invalid transport.

This validation happens before the MCP process is actually started. Therefore, enabled = false does not make a transport-less MCP entry valid.

1. The plugin configuration model separates transport ownership from user policy:

• the plugin manifest provides the transport;
• the user configuration mainly controls enablement and tool policy.

Therefore, an object containing only { "enabled": true } or { "enabled_tools": [...] } cannot be treated as a complete standalone MCP server definition.

1. The #40715 comments show that the bundled codex-app-tools manifest itself includes a complete Windows stdio transport, including command: "cmd.exe" and launcher arguments. Therefore, the more likely problem is not that the manifest lacks a transport, but that Desktop loses, omits, or overwrites the transport fields when constructing the request sent to the WSL app-server.

1. The experiments documented in #40715 are consistent with this boundary:

• removing the bundled plugin allows a direct app-server thread/start request to succeed;
• the Desktop app later reconciles and reinstalls the bundled plugin;
• the failure returns after reconciliation;
• using /bin/false as a dummy transport and disabling the server can restore ordinary chat, but the Desktop-owned tools are lost.

1. Codex 0.149 and 0.150 both reject the same transport-less MCP object. This is therefore not simply a WSL CLI version compatibility problem. The fact that the Windows-native path works while the WSL path fails points more directly to host-specific Desktop request construction.

1. #40860 reports the same parser-level error on macOS. That report does not provide the same WSL JSON-RPC payload, so it cannot directly prove that macOS and WSL use exactly the same internal code path. However, it suggests that the broader problem may be an incomplete Desktop-generated internal MCP overlay, rather than only a Windows/WSL-specific configuration error.

A likely configuration-composition failure

One implementation mechanism worth checking is a same-key configuration overlay collision.

The public override builder constructs a session-level TOML layer for dotted paths such as mcp_servers.codex_app. If Desktop first inserts a complete manifest-derived mcp_servers.codex_app table and later inserts another table at the same path containing only enabled or enabled_tools, the later policy table may shadow the transport fields.

This could explain the following observations:

• the bundled manifest contains a valid command;
• the WSL app-server actually receives a request object containing only policy fields;
• the parser fails before any MCP child process is started.

However, this section should be explicitly treated as an implementation hypothesis, not as a root cause confirmed by the maintainers. The public configuration stack also contains recursive table-merge logic in other paths, so the exact precedence and merge behavior should be verified with a focused test or by logging the final request/config layer generated by Desktop.

Recommended fix

1. Fix the Desktop-side request construction first

The Desktop layer is the component that owns the codex-app-tools transport information and knows which host runs the app-server. Therefore, the primary fix should be made in Desktop.

• A Windows-native app-server can continue to use the existing Windows launcher.
• A WSL/Linux app-server should receive a command/args/cwd that is actually resolvable from the WSL environment.
• Alternatively, the Desktop-owned capability could use the supported hosted/extension MCP path.
• If no valid transport can be resolved for the target host, Desktop should omit the internal mcp_servers.codex_app entry completely.

A policy-only object must not be sent to the generic MCP parser as if it were a complete server definition.

If a particular host cannot start the Desktop-owned MCP capability, ordinary thread creation and resumption should still proceed with a diagnostic warning. Missing internal capability should not make an otherwise valid thread appear to have a broken user config.toml.

2. Add a narrowly scoped backend defense if needed

If Desktop compatibility requires a backend change, the safer design would be to introduce an explicit, typed policy overlay:

• first resolve a complete MCP server from a trusted plugin manifest or another trusted source;
• then apply enabled, enabled_tools, and similar policy fields to that existing server.

The backend should not globally accept every transport-less MCP table. In particular:

• a normal user-defined MCP server with neither command nor url should remain invalid;
• an unknown server with only enabled or enabled_tools should remain invalid, or produce a more structured error;
• a policy-only overlay should be accepted only when a valid base server already exists;
• the parser should not unconditionally special-case every server named codex_app without an explicit protocol contract.

The singular codex_app Desktop-owned namespace should also remain distinct from the plural codex_apps hosted Apps/connector namespace used by the open-source runtime.

3. Make plugin disablement and reconciliation authoritative

When codex-app-tools is explicitly disabled, that state should prevent its MCP, app, connector, and tool contributions from being injected into the request.

Desktop reconciliation should preserve an explicit disabled state instead of reinstalling and re-enabling the bundled plugin on the next launch. This behavior should be tested independently from transport parsing.

The /bin/false workaround described in #40715 is useful as a diagnostic workaround, but it is not a complete fix: it removes the Desktop-owned capabilities automation_update, create_thread, send_message_to_thread, fork_thread, and handoff_thread, and it may be undone by plugin reconciliation.

4. Improve the diagnostic error boundary

When an internal Desktop-owned MCP contribution cannot be resolved for the target host, the error should identify the Desktop/plugin transport problem. It should not tell the user to modify config.toml when the invalid object was generated in memory by Desktop.

Suggested regression tests

The tests should cover both:

1. restoration of Desktop compatibility; and
2. preservation of strict validation for ordinary MCP configuration.

The test matrix should include:

• parser boundaries for command, url, both fields together, and neither field;
• the enabled and enabled_tools request-override forms observed in existing reports;
• cold and normal thread/start and thread/resume paths;
• plugin enablement, disablement, and reconciliation;
• Windows-native, WSL/Linux, Windows interop disabled, and macOS host scenarios;
• verification that the final Desktop-generated request contains either a complete transport for codex_app or no such entry at all;
• verification that a configuration error does not corrupt thread history or start an unnecessary MCP child process.

Acceptance criteria

A fix should satisfy all of the following:

• WSL thread/start and thread/resume succeed with the bundled plugin enabled;
• Windows-native behavior remains unaffected;
• no transport-less internal mcp_servers.codex_app object reaches the generic MCP parser;
• disabling the plugin prevents its capability contribution and remains effective after reconciliation;
• ordinary user-authored transport-less MCP configurations remain strictly rejected;
• users are not instructed to modify config.toml when the invalid configuration was generated by Desktop;
• users do not need to downgrade the WSL CLI or permanently disable all Desktop-owned tools.

Overall, this looks more like a compatibility regression at the internal MCP injection boundary between Desktop and app-server than a problem with the user's configuration file or thread history.

same issue here

<img width="609" height="195" alt="Image" src="https://github.com/user-attachments/assets/a50685b1-6657-4b8e-881a-d8afc9518787" />
same issue here

I can reproduce the same issue on Windows 10.

Environment:

• Microsoft Windows NT 10.0.19045.0 x64
• WSL2 with Ubuntu 24.04
• Codex Desktop 26.820.7780.0
• Desktop-bundled WSL runtime: codex-cli 0.150.0-alpha.8
• Separately installed WSL CLI: codex-cli 0.149.1

Additional control tests:

• Normal Codex CLI inside WSL works correctly.
• The Desktop-bundled 0.150.0-alpha.8 binary also runs mcp list successfully when invoked manually and reports no MCP servers configured.
• Codex Desktop works correctly when runCodexInWindowsSubsystemForLinux = false in a clean Windows-native test directory.
• Regenerating the codex_apps_tools / codex_apps_server_info caches did not resolve the WSL failure.
• Temporarily disabling the bundled codex-app-tools plugin did not change the behavior.

This appears consistent with the reported Desktop → WSL app-server initialization issue rather than a problem in the user's config.toml.

Same issue here on Windows + WSL2 with Codex Desktop 26.820.7780.0.

I checked my config.toml and there is no mcp_servers.codex_app entry in it.

I also found the bundled codex-app-tools plugin and its desktop-mcp.json does have a valid command/args transport. I even tried disabling the plugin and moving its cached/bundled copies out of .codex, but the error is still exactly the same:

invalid transport in mcp_servers.codex_app

So this really looks like something is being injected incorrectly by the Desktop → WSL path, not an issue with the user config itself.

Happy to test a fix if needed.

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.

hahaha,me too.It is a good thing that we all have this problem.

临时解决方案
[mcp_servers.codex_app]
command = "/bin/false"
enabled = false

same issue

• Desktop app 26.820.7780.0
• WSL execution enabled
• Bundled CLI 0.150.0-alpha.8
• Transport-less mcp_servers.codex_app injected during both start and resume

Additional reproduction and workaround limitation (Windows + WSL2)

I can reproduce this issue on Codex Desktop with the app configuration reporting version 26.820.60940 and the WSL agent path enabled:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

The observed error is the same as in this issue:

invalid transport in mcp_servers.codex_app

Reproduction observations

1. Existing WSL-hosted thread: resuming an existing thread fails with the reported mcp_servers.codex_app transport error.
2. New thread in the same WSL project: creating a brand-new thread also fails with the same error. In this environment, the failure is therefore not limited to thread/resume.
3. User configuration check: the user-level config.toml does not contain a [mcp_servers.codex_app] entry. The configured MCP entry that is present (node_repl) has an explicit command transport.
4. WSL-side Codex state check: ~/.codex exists inside WSL, but there is no ~/.codex/config.toml and no symlink redirecting that directory to Windows.

Windows-native control test

Switching Agent environment → Windows native, restarting Codex Desktop, and reopening the same previously failing thread succeeds. This is a strong control indicating that the failure is specific to the Desktop → WSL execution path in this setup.

However, Windows-native mode is not a complete operational workaround when the repository itself lives in the WSL filesystem.

For a repository whose real path is of the form:

/home/<user>/Projects/<repo>

Codex Desktop in Windows-native mode exposed/configured the workspace as the equivalent of:

C:\home\<user>\Projects\<repo>

A read-only test from that thread:

git status --short --branch

then failed before Git could run because the Windows runtime rejected the working directory:

CreateProcessWithLogonW
error 267 (invalid directory)

Running the same Git command directly inside WSL, against the actual repository, worked normally and showed a clean tracked branch at the time of the test.

So the Windows-native switch is useful as a diagnostic control and can make affected threads open again, but for repositories stored under the WSL filesystem it may require relocating/duplicating the repository to a true Windows filesystem before normal Desktop work is possible. That makes it a poor general workaround for users intentionally keeping development repositories inside WSL.

What these tests support

These observations are consistent with the issue report's conclusion that the failure is introduced on the Codex Desktop → WSL path, rather than by an invalid user config.toml.

They also add two practical data points:

• the same failure can occur when starting a new WSL thread, not only when resuming an existing one;
• switching to Windows-native execution can bypass the original transport error but introduces a separate workspace-path problem for repositories that remain inside WSL.

I am not claiming to have independently verified the issue's internal JSON-RPC/root-cause analysis; the statements above are limited to directly observed behavior and configuration checks.

No repository files were modified during these tests.

---

Disclosure: This comment was generated by ChatGPT from my observed test results and is being posted through my GitHub account at my explicit request. ChatGPT did not independently access my computer; the observations above come from screenshots, configuration files, and command outputs that I provided for analysis.

Independently reproduced on Windows 11 + WSL2, same app version 26.820.7780.0. Your analysis matches everything I measured, so just three additions:

1. thread/start fails too, not only thread/resume. Creating a brand-new chat produces the identical error, so the fix needs to cover both paths. Counted across one day of desktop logs on the affected machine:

92  method=thread/resume
11  method=thread/start

2. The apps_mcp_path_override warning is a red herring — worth stating explicitly, because it is emitted by codex_app_server::request_processors::config_processor right alongside the failure and looks like the cause:

WARN ignoring invalid experimental feature enablement keys: apps_mcp_path_override

It appears the same number of times in a working session (runCodexInWindowsSubsystemForLinux = false, zero invalid transport) as in a failing one, and it predates the regression — it is present in logs from days before the update. Setting [features] apps_mcp_path_override = true in config.toml also changes nothing.

3. Extra confirmation that the entry is assembled in-memory. Beyond disabling the plugin, I also rewrote the bundled plugin's desktop-mcp.json — in both the installed plugin cache and the materialised bundled-marketplace copy — to a valid POSIX entry (scripts/launch_codex_app_tools_mcp plus server.mjs, absolute paths, cwd set). The patched files survive an app restart untouched, and the error is unchanged. So on the WSL path the manifest's transport fields are not merely lost, they are never consulted for this entry.

---

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.

Additional confirmation: WSL launch command omits the Desktop MCP transport

This is an additional reproduction on:

• Codex Desktop package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Desktop log release: 26.820.60940
• WSL bundled CLI/app-server: 0.150.0-alpha.8
• Windows 11 build 26100, WSL2 Ubuntu 26.04

The Windows and WSL agent paths differ in the app-server command line:

• Windows agent environment (working): the app-server command includes a complete request-level override equivalent to:

-c "mcp_servers.codex_app={command=\"cmd.exe\", args=[...launch_codex_app_tools_mcp.cmd..., server.mjs], cwd=..., env=...}"

• WSL agent environment (failing): the app-server command does not include that complete mcp_servers.codex_app transport. Nevertheless, during thread/start, Desktop injects a request-level mcp_servers.codex_app policy object containing enabled_tools (and/or enabled) without command or url.

That produces:

failed to load configuration: invalid transport in mcp_servers.codex_app

This also explains why the error is misleading: the user's config.toml does not need to contain mcp_servers.codex_app; the invalid object is assembled by Desktop for the WSL app-server request.

Isolation and transport validation

1. A WSL app-server thread/start with the injected policy-only entry fails during configuration parsing.
2. Adding any syntactically valid transport to that request makes the invalid transport error disappear.
3. Supplying the actual codex-app-tools transport, together with CODEX_APP_TOOLS_PIPE_PATH and the required WSLENV propagation, brings the codex_app MCP status to ready.
4. Windows agent environment works with the same Desktop installation and account, isolating the regression to the Desktop → WSL launch/injection path.

Workaround tested

A local wrapper can be registered as the WSL-side transport:

[mcp_servers.codex_app]
command = "/home/<wsl-user>/.local/bin/codex-app-tools-wsl"

The wrapper:

• discovers the Desktop named pipe matching \\\\.\\pipe\\codex-browser-use-*;
• sets CODEX_APP_TOOLS_PIPE_PATH;
• configures WSLENV so the pipe path crosses the WSL/Windows boundary;
• launches the bundled codex-app-tools/server.mjs through Windows cmd.exe.

With this workaround, WSL thread/start reaches codex_app: ready. It is only a temporary compatibility workaround; the product fix should make Desktop pass the complete transport (or omit the entry) on the WSL path.

No personal usernames, workspace names, pipe IDs, or session IDs are included here.

这么严重的bug，都过去几个小时了，还不修？？就这？？

same here...

<img width="778" height="219" alt="Image" src="https://github.com/user-attachments/assets/71b949e4-4f13-460c-b843-4b210928afc8" />
Same issue

How is it even an issue in prod? How many devs already performed a seppuku?

Additional reproduction and root-cause evidence from Windows Store build 26.820.7780.0 with the bundled WSL CLI 0.150.0-alpha.8:

• The persisted user/project TOML did not define mcp_servers.codex_app.
• The failure occurred for both thread/start and thread/resume, including ChatGPT Project-backed tasks.
• Inspecting this build's packaged renderer/main bundle shows an asymmetry: the full internal mcp_servers.codex_app transport override is supplied only on the non-WSL path, while the renderer still adds mcp_servers.codex_app.enabled_tools for local WSL thread requests.
• The resulting WSL request therefore contains an MCP table with fields such as enabled_tools but no command or url, which the bundled app-server correctly rejects as invalid transport.

A temporary file-level workaround was validated:

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

After a full app restart, new WSL tasks start successfully. This is only a diagnostic workaround: it disables Codex app-specific task/automation MCP tools inside WSL, so it is not an acceptable product fix.

Expected product fix: when constructing WSL thread start/resume config, either inject a complete Linux-usable transport for codex_app, or omit the entire table including enabled_tools. The error should also identify Desktop-generated runtime config rather than instructing users to repair a clean config.toml.

UPD: disregard, sorry, I can confirm that 26.818.8289.0 specifically works fine.

DO NOT TRY TO REINSTALL OLDER VERSIONS
they also broke history compatibility so you'll only get other errors instead

DO NOT TRY TO REINSTALL OLDER VERSIONS they also broke history compatibility so you'll only get other errors instead

Mileage may vary, but I reverted to the closest previous version (26.818) without trouble.

Yes, sorry, I can confirm that 26.818.8289.0 specifically works fine.

yeah same here after the update

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.

Independent reproduction on the same Desktop/Codex build.

Environment:

• Windows 11 10.0.26200
• Microsoft Store Codex Desktop 26.820.7780.0
• bundled codex 0.150.0-alpha.8
• [desktop] runCodexInWindowsSubsystemForLinux = true

One additional observation: this affects brand-new threads for me as well as existing/resumed threads, so the malformed codex_app override may also be present on the thread/start path, not only thread/resume.

I also ran the Desktop-bundled codex.exe:

codex.exe doctor --json

It reports:

config.load: ok
CODEX_HOME: C:\Users\Chinoman10\.codex
config.toml parse: ok
configured MCP servers: 1
MCP server: node_repl

There is no mcp_servers.codex_app entry in the physical config and doctor does not see one. So this independently confirms that codex_app is introduced after normal config loading / by the Desktop request-level configuration.

Happy to collect a thread/start JSON-RPC payload or additional diagnostics if useful.

WSL-mode Chat Creation Fails with invalid transport in mcp_servers

Bug Description

After the recent update of the Codex Desktop app, creating or resuming chat threads in WSL-hosted mode/paths completely fails. The UI blocks the conversation with the following error:"ChatGPT failed to load config.toml, so this thread cannot continue. Please fix config.toml: invalid transport in mcp_servers.codex_app (or mcp_servers.node_repl)."While the native Windows environment works perfectly fine, running Codex via WSL or interacting with threads in the WSL file system triggers this deadlock.Relevant

Configuration Snippet

Checking the generated config.toml reveals that the desktop app automatically injects native Windows environment variables and a Named Pipe directory into the MCP server configuration:toml[mcp_servers.node_repl]
args = []
command = "/mnt/c/Users/Administrator/AppData/Local/OpenAI/Codex/runtimes/cua_node/950613ca46815e82/bin/node_repl.exe"
startup_timeout_sec = 120

[mcp_servers.node_repl.env]
...
SKY_CUA_NATIVE_PIPE = "1"
SKY_CUA_NATIVE_PIPE_DIRECTORY = '\\.\pipe\codex-computer-use-54dca94f-2c05-4913-a981-899dfb73e3bf'
WSLENV = "NODE_REPL_NATIVE_PIPE_CONNECT_TIMEOUT_MS/w:..."

Probable Root Cause

The root cause is an environment leak/pollution across the OS boundary:

1. To support "Computer Use" or Node execution features, the Windows Desktop app registers a Windows-specific Named Pipe (\\.\pipe\...) as the transport layer for the MCP server (node_repl).
2. Due to the explicit WSLENV flags, these Windows-specific pipe paths are shared with the WSL Linux environment.
3. When the Linux-side Codex app-server processes the configuration, its MCP parser fails to recognize the Windows pipe format—as Linux only natively supports stdio or network sockets (http/ws) for MCP transport—subsequently throwing the invalid transport error and locking the thread.

The scope and root cause here are now documented in considerable detail, and more affected users keep arriving. Why has there still been no visible acknowledgement from an OpenAI maintainer? For people whose repositories and toolchains must run in WSL this is a full work blocker, not a minor feature regression. A short confirmation that the incident is known and being worked on would already be valuable.

Windows 11 + WSL2. Codex Desktop shows "ChatGPT can't load config.toml... invalid transport in mcp_servers.codex_app" when resuming an existing WSL-hosted thread. The issue started after updating to the latest desktop version. My config.toml does not contain an invalid codex_app transport.

Same issue here with WSL. Has any fix come up?

Confirming the same issue here on Windows 11 + WSL2.
Codex Desktop fails to create new WSL tasks with:
failed to load configuration: invalid transport in mcp_servers.codex_app

Existing WSL tasks also fail to resume with:
ChatGPT can't load config.toml, so this thread can't resume.

Additional diagnostic update:

I identified the actual WSL Codex runtime bundled/used by Desktop:

/mnt/c/Users/Ryan/.codex/bin/wsl/bf0dd1e87d338bce/codex

Version:

codex-cli 0.150.0-alpha.8

This is separate from my standalone WSL Codex CLI:

/home/ryan/.local/bin/codex

which is version 0.141.0.

I also confirmed again that /home/ryan/.codex/config.toml contains no [mcp_servers.*] entries and no codex_app reference. A recursive search of WSL-side TOML files likewise finds no codex_app or mcp_servers configuration.

The clean-room reproduction remains:

• Ubuntu running under WSL2
• Brand-new empty project at /home/ryan/dev/codex-empty-test
• No project .codex/config.toml
• Desktop WSL runtime 0.150.0-alpha.8
• Creating the first chat in Desktop immediately fails with:

failed to load configuration: invalid transport in mcp_servers.codex_app

For comparison, launching my standalone Codex CLI (0.141.0) directly inside the same WSL distro and the same empty directory succeeds and /status works.

This further isolates the problem to the Codex Desktop → WSL runtime launch/configuration path rather than WSL itself or user/project configuration.

Feedback ID:
no-active-thread-01a03f1d-ce0c-7810-91e2-63cfb9438357

After the latest Codex Desktop update on Windows, I can no longer open several existing projects/threads when using WSL.

The error is:

invalid transport in mcp_servers.codex_app

The strange part is that I do not have any mcp_servers.codex_app entry in my ~/.codex/config.toml, so this looks like something Codex Desktop is injecting internally.

My setup is:

integratedTerminalShell = "wsl"
runCodexInWindowsSubsystemForLinux = true

These threads were working normally before the update, and the session files are still present under .codex, so it does not look like the data itself was deleted.

I also tested the suggested workaround of switching to:

runCodexInWindowsSubsystemForLinux = false

That avoids the codex_app error, but then the native Windows Codex runtime fails with:

failed to initialize sqlite state runtime under C:\Users\<USER>\.codex

So at the moment I am stuck between:

WSL mode -> invalid mcp_servers.codex_app
Windows mode -> SQLite state runtime fails

I normally use Codex through WSL and would really prefer not to switch my whole workflow to native Windows.

This is quite serious for me because I have a lot of important project context inside those existing Codex threads.

Is there any known workaround for WSL users, or is a fix for this regression already being worked on?

I have an experimental workaround that preserves WSL mode (runCodexInWindowsSubsystemForLinux = true) and is working for me on:

• Windows 11 + WSL2 Ubuntu
• Codex Desktop 26.820.7780.0
• bundled WSL Codex 0.150.0-alpha.8

I have tested:

• creating a new thread
• resuming an existing thread
• sending a file/prompt to an existing thread
• normal agent execution / code-mode execution

All are working with the workaround applied.

Additional root-cause detail

I put a transparent JSON-RPC proxy between Codex Desktop and the WSL codex app-server and captured the actual thread/start / thread/resume requests.

On my build the malformed request-level config is sent as a flattened key:

mcp_servers.codex_app.enabled_tools

For example, thread/start.config contains:

...
mcp_servers.node_repl
mcp_servers.codex_app.enabled_tools

but no:

mcp_servers.codex_app.command

or:

mcp_servers.codex_app.url

The same malformed flattened key is present on thread/resume.

Removing the transport-less mcp_servers.codex_app.* request-level keys before forwarding the JSON-RPC request makes both operations succeed.

Importantly, this does not require modifying config.toml.

Temporary WSL-preserving workaround

This is a hack and should only be used until an official fix ships.

It requires a native Linux Bun installation inside WSL.

1. Locate the WSL Codex runtime

Codex Desktop currently launches something similar to:

/mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex \
  -c features.code_mode_host=true \
  app-server \
  --analytics-default-enabled

The <hash> directory changes between builds.

In my case it was:

/mnt/c/Users/<user>/.codex/bin/wsl/bf0dd1e87d338bce/

That directory contained both:

codex
codex-code-mode-host

2. Copy the real runtime into the Linux filesystem

Do not leave the backup beside the staged Windows binary: Codex Desktop re-stages that directory on startup and deletes/replaces sibling files.

Instead:

cp -p /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex \
  ~/codex-desktop-wsl-real

cp -p /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex-code-mode-host \
  ~/codex-code-mode-host

chmod 755 ~/codex-desktop-wsl-real ~/codex-code-mode-host

The codex-code-mode-host copy is required.

Without it, normal threads may open successfully but execution later fails with:

local execution helper is missing:
/home/<user>/codex-code-mode-host

The real Codex executable resolves that helper relative to its executable directory.

3. Create the JSON-RPC shim

I used the following Bun/TypeScript proxy as ~/codex-app-shim.ts:

import { appendFileSync } from "node:fs";

const REAL_CODEX = "/home/<wsl-user>/codex-desktop-wsl-real";
const LOG_FILE = "/tmp/codex-app-shim.log";

function isObject(value: unknown): value is Record<string, unknown> {
  return typeof value === "object" && value !== null && !Array.isArray(value);
}

function hasValidTransport(value: unknown): boolean {
  if (!isObject(value)) return false;

  return (
    (typeof value.command === "string" && value.command.length > 0) ||
    (typeof value.url === "string" && value.url.length > 0)
  );
}

function patchJsonRpcLine(line: string): {
  line: string;
  changed: boolean;
  reason?: string;
} {
  let message: unknown;

  try {
    message = JSON.parse(line);
  } catch {
    return { line, changed: false };
  }

  if (!isObject(message)) {
    return { line, changed: false };
  }

  if (
    message.method !== "thread/start" &&
    message.method !== "thread/resume"
  ) {
    return { line, changed: false };
  }

  const params = message.params;
  if (!isObject(params)) {
    return { line, changed: false };
  }

  const config = params.config;
  if (!isObject(config)) {
    return { line, changed: false };
  }

  let changed = false;

  const flatCodexAppKeys = Object.keys(config).filter(
    (key) =>
      key === "mcp_servers.codex_app" ||
      key.startsWith("mcp_servers.codex_app."),
  );

  const hasFlatTransport = flatCodexAppKeys.some(
    (key) =>
      key === "mcp_servers.codex_app.command" ||
      key === "mcp_servers.codex_app.url",
  );

  const exactCodexApp = config["mcp_servers.codex_app"];
  const hasExactTransport = hasValidTransport(exactCodexApp);

  // Current Desktop WSL regression:
  // settings such as mcp_servers.codex_app.enabled_tools are sent
  // without a command/url transport. Remove the incomplete override
  // as a unit.
  if (
    flatCodexAppKeys.length > 0 &&
    !hasFlatTransport &&
    !hasExactTransport
  ) {
    for (const key of flatCodexAppKeys) {
      delete config[key];
    }

    changed = true;
  }

  // Also support a nested representation defensively.
  if (
    isObject(config.mcp_servers) &&
    Object.hasOwn(config.mcp_servers, "codex_app") &&
    !hasValidTransport(config.mcp_servers.codex_app)
  ) {
    delete config.mcp_servers.codex_app;
    changed = true;
  }

  return {
    line: changed ? JSON.stringify(message) : line,
    changed,
    reason: changed
      ? `removed transport-less mcp_servers.codex_app from ${message.method}`
      : undefined,
  };
}

function log(message: string): void {
  try {
    appendFileSync(
      LOG_FILE,
      `${new Date().toISOString()} pid=${process.pid} ${message}\n`,
      "utf8",
    );
  } catch {
    // Logging must never interfere with app-server stdio.
  }
}

async function proxy(): Promise<void> {
  const child = Bun.spawn(
    [REAL_CODEX, ...Bun.argv.slice(2)],
    {
      stdin: "pipe",
      stdout: "pipe",
      stderr: "pipe",
      env: process.env,
    },
  );

  log(`started child pid=${child.pid}`);

  const stderrTask = (async () => {
    for await (const chunk of child.stderr) {
      try {
        appendFileSync(LOG_FILE, chunk);
      } catch {
        // Never contaminate protocol stdout/stderr.
      }
    }
  })();

  const stdoutTask = (async () => {
    for await (const chunk of child.stdout) {
      process.stdout.write(chunk);
    }
  })();

  const stdinTask = (async () => {
    const decoder = new TextDecoder();
    let buffered = "";

    for await (const chunk of Bun.stdin.stream()) {
      buffered += decoder.decode(chunk, { stream: true });

      while (true) {
        const newline = buffered.indexOf("\n");
        if (newline < 0) break;

        const raw = buffered.slice(0, newline);
        buffered = buffered.slice(newline + 1);

        const result = patchJsonRpcLine(raw);

        if (result.changed) {
          log(result.reason ?? "patched request");
        }

        child.stdin.write(result.line + "\n");
        child.stdin.flush();
      }
    }

    buffered += decoder.decode();

    if (buffered.length > 0) {
      const result = patchJsonRpcLine(buffered);

      if (result.changed) {
        log(result.reason ?? "patched final request");
      }

      child.stdin.write(result.line);
      child.stdin.flush();
    }

    child.stdin.end();
  })();

  const forwardSignal = (signal: NodeJS.Signals) => {
    try {
      child.kill(signal);
    } catch {
      // Child may already have exited.
    }
  };

  process.on("SIGINT", () => forwardSignal("SIGINT"));
  process.on("SIGTERM", () => forwardSignal("SIGTERM"));
  process.on("SIGHUP", () => forwardSignal("SIGHUP"));

  await Promise.all([
    stdinTask,
    stdoutTask,
    stderrTask,
    child.exited,
  ]);

  process.exitCode = child.exitCode ?? 1;
}

const args = Bun.argv.slice(2);

if (!args.includes("app-server")) {
  const child = Bun.spawn([REAL_CODEX, ...args], {
    stdin: "inherit",
    stdout: "inherit",
    stderr: "inherit",
    env: process.env,
  });

  process.exitCode = await child.exited;
} else {
  await proxy();
}

Replace <wsl-user> in REAL_CODEX.

4. Create a launcher

For example:

cat > ~/codex-desktop-wsl-shim <<'EOF'
#!/bin/sh
exec /home/<wsl-user>/.bun/bin/bun /home/<wsl-user>/codex-app-shim.ts "$@"
EOF

chmod 755 ~/codex-desktop-wsl-shim

5. Bind-mount it over Desktop's staged WSL binary

Simply replacing the staged codex file does not work because Desktop re-stages the ELF binary on startup.

A file bind mount does survive that restaging:

sudo mount --bind \
  ~/codex-desktop-wsl-shim \
  /mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex

Verification:

file /mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex

should show the shell script rather than the ELF binary.

Then reopen Codex Desktop.

The resulting process chain should be approximately:

Codex Desktop
  -> WSL
    -> codex-desktop-wsl-shim
      -> Bun JSON-RPC proxy
        -> ~/codex-desktop-wsl-real app-server

The proxy removes only transport-less mcp_servers.codex_app.* overrides from thread/start / thread/resume.

Everything else is forwarded unchanged.

Caveats

This is intentionally a temporary workaround.

• The bind mount disappears after wsl --shutdown / reboot and must be reapplied.
• A future Codex update may use a different <hash> directory, requiring the real codex and codex-code-mode-host files to be recopied and the bind mount reapplied to the new path.
• Do not forget codex-code-mode-host; thread loading can appear fixed while actual execution remains broken without it.
• I would not modify config.toml for this issue. The malformed configuration is injected by Desktop at request time.
• Unmounting restores the original staged binary immediately:

sudo umount \
  /mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex

After applying this I can create new WSL threads, resume existing WSL threads, attach/send files, and execute normal agent/code-mode work while keeping:

[desktop]
runCodexInWindowsSubsystemForLinux = true

Hopefully the capture of the flattened mcp_servers.codex_app.enabled_tools key helps narrow down where the Desktop WSL config translation is dropping the transport.

This has worked for me https://github.com/openai/codex/issues/40881#issuecomment-5427361016 (WSL2 + Windows 11 + codex-cli 0.149.1)

Allows me to see old threads, no mcp error. It gave a couldn't open file, but... it is working for now for me.

I can independently reproduce this issue on Windows 11 with WSL2.

Environment:

• ChatGPT/Codex Desktop app
• Current version: 26.820.7780.0
• Previous working version: 26.818.8289.0
• WSL mode enabled: runCodexInWindowsSubsystemForLinux = true

My local logs show that on 2026-08-25 the app was running build 26.818.8289.0, detected the update to 26.820.7780.0, and completed the download. After the update, resuming WSL-hosted threads began failing with:

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

The first recorded failure was on 2026-08-26 at 00:31:23Z.

The NotebookLM MCP remains enabled and healthy in the CLI, and no user MCP configuration was changed. The codex_app entry is not present in my user config.toml; it appears to be injected by the Desktop app on the WSL path.

This confirms the same regression described here and suggests the issue is specifically related to the WSL integration in Desktop 26.820.7780.0.

Additional diagnostic update: I identified the actual WSL Codex runtime bundled/used by Desktop: /mnt/c/Users/Ryan/.codex/bin/wsl/bf0dd1e87d338bce/codex Version: codex-cli 0.150.0-alpha.8 This is separate from my standalone WSL Codex CLI: /home/ryan/.local/bin/codex which is version 0.141.0. I also confirmed again that /home/ryan/.codex/config.toml contains no [mcp_servers.*] entries and no codex_app reference. A recursive search of WSL-side TOML files likewise finds no codex_app or mcp_servers configuration. The clean-room reproduction remains: Ubuntu running under WSL2 Brand-new empty project at /home/ryan/dev/codex-empty-test No project .codex/config.toml Desktop WSL runtime 0.150.0-alpha.8 * Creating the first chat in Desktop immediately fails with: failed to load configuration: invalid transport in mcp_servers.codex_app For comparison, launching my standalone Codex CLI (0.141.0) directly inside the same WSL distro and the same empty directory succeeds and /status works. This further isolates the problem to the Codex Desktop → WSL runtime launch/configuration path rather than WSL itself or user/project configuration. Feedback ID: no-active-thread-01a03f1d-ce0c-7810-91e2-63cfb9438357

Final isolation result:

I temporarily changed:

runCodexInWindowsSubsystemForLinux = false

and fully restarted Codex Desktop.

Using the same Desktop build (26.820.7780.0) and the same local Windows repository (C:\Users\Ryan\Documents\ChatGPT\arr-remux), Codex then starts and runs normally.

With:

runCodexInWindowsSubsystemForLinux = true

the same repository fails with:

failed to load configuration: invalid transport in mcp_servers.codex_app

So repository location is not the determining factor. A Windows-hosted repository also fails when the Codex agent itself is configured to run through WSL.

Current isolation:

• Windows agent path: works
• WSL agent path: fails
• WSL2 confirmed
• Clean WSL project reproduces
• Windows/WSL/project TOML files contain no mcp_servers.codex_app
• Desktop-bundled WSL runtime: codex-cli 0.150.0-alpha.8

This appears conclusively isolated to the Desktop → WSL agent launch/configuration path.

Additional before/after evidence: dummy stdio entry unblocks new WSL chats

I reproduced the same failure with:

• Codex Desktop: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Bundled WSL CLI: codex-cli 0.150.0-alpha.8
• Windows: 10.0.19045.7663
• Bundled plugin: codex-app-tools@openai-bundled 0.1.3

The plugin's cached desktop-mcp.json contains a real codex_app transport using cmd.exe and the bundled launcher. Nevertheless, WSL thread/start repeatedly failed with:

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

Local log evidence:

• 11 recent Desktop log files contained 173 matches.
• One directly observed thread/start failed at 2026-08-26T15:10:50.380Z with failureReason=invalid_config.
• The last observed run with this error ended at 15:13:13.760Z.

I then applied this temporary user-config workaround:

[mcp_servers.codex_app]
transport = "stdio"
command = "echo"
args = ["dummy"]

After restarting the app, the next Desktop log started at 15:13:16.094Z, contained zero invalid transport / failed to load configuration occurrences, and recorded two thread/start completions with errorCode=null at 15:13:34.070Z and 15:13:34.071Z. A newly created conversation then recorded activity at 15:13:43.776Z.

This workaround is diagnostic only. echo dummy is not an MCP/JSON-RPC server and exits immediately, so it can cause EOF/handshake failures and can mask or replace the actual Desktop-owned codex_app tools.

The product should either inject a complete host-valid internal transport or omit the internal entry. A malformed Desktop-generated internal MCP overlay should not block all new chat creation or require manual TOML surgery; the app should recover with an actionable diagnostic while preserving ordinary chat access.

same issue

Alternative WSL-preserving workaround: Codex VS Code extension

For anyone primarily blocked because they need to keep working natively in WSL, I've had good results using the official OpenAI Codex extension in VS Code with the project opened through VS Code Remote WSL.

This does not repair Codex Desktop or make the broken Desktop threads resumable, but it has allowed me to continue the same project workflow without switching the project to Windows-native execution.

Tested successfully with:

• VS Code opened natively in WSL2 Ubuntu
• repository under /home/..., not via \\wsl.localhost
• Codex agent execution in WSL
• DDEV/Docker workflow
• Git
• project workflow/report artifacts
• chrome-devtools-mcp registered in WSL ~/.codex/config.toml
• Chrome/CDP browser inspection from Codex

One important detail: after adding an MCP server to the WSL Codex config, I had to start a fresh VS Code Codex agent/session before the MCP tools appeared; the existing session did not hot-reload them.

So for my use case this has been a practical temporary workaround while waiting for the Desktop → WSL regression to be fixed, without changing runCodexInWindowsSubsystemForLinux or moving the development workflow to Windows.

Fixed it with my chatGPT, lol

This is the comand it told me to run and it worked. Ask your GPT to match you PC settings, because i am using MacOS.

cfg="$HOME/.codex/config.toml"
backup="$cfg.backup-$(date +%Y%m%d-%H%M%S)"

cp "$cfg" "$backup"

if ! grep -q '^\[mcp_servers\.codex_app\]$' "$cfg"; then
  printf '\n[mcp_servers.codex_app]\ncommand = "/usr/bin/true"\nenabled = false\n' >> "$cfg"
fi

echo "Backup: $backup"
echo "Current MCP servers:"
"/Applications/ChatGPT.app/Contents/Resources/codex" mcp list

Confirming this on Windows + WSL2 with Codex Desktop 26.820.60940 and bundled codex-cli 0.150.0-alpha.8.

I get the same invalid transport in mcp_servers.codex_app failure when runCodexInWindowsSubsystemForLinux = true. The codex_app block is not present in my config.toml and appears to be injected dynamically by Desktop.

Setting runCodexInWindowsSubsystemForLinux = false restores normal operation.

During troubleshooting I also regenerated the local Codex state database. The underlying session files remained intact, but Desktop temporarily displayed No chats / No projects until the database reindexed them. My active DB eventually indexed 48 threads, while the preserved previous DB contained only 11 indexed threads despite roughly 47 session files existing.

Ubuntu/WSL2 itself is healthy and the Linux repository/toolchain remain intact. This appears isolated to the Desktop Windows-to-WSL agent bridge and Desktop session/index state.

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

Environment:

• Codex Desktop: 26.820.60940
• OS: Windows 11 25H2
• WSL: WSL 2
• Linux distribution: Ubuntu
• Project is located and executed inside Ubuntu/WSL 2
• runCodexInWindowsSubsystemForLinux = true

When opening an existing thread, Codex shows:

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

The same problem also happens when creating a completely new chat:

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

There is no [mcp_servers.codex_app] entry in my C:\Users\RENE\.codex\config.toml, so this appears to be related to the configuration injected internally by Codex Desktop when running through WSL 2.

Disabling the codex-app-tools@openai-bundled plugin did not fix the issue.

As a workaround, changing:

runCodexInWindowsSubsystemForLinux = true

to:

runCodexInWindowsSubsystemForLinux = false

allows Codex Desktop to create/open chats again. However, this is not ideal because my development environment and projects run inside WSL 2.

Independent reproduction on the current Stable Windows package. This appears to match this issue exactly.

Environment

• Microsoft Store package: OpenAI.Codex 26.820.7780.0
• About dialog / Codex & OWL: 26.820.60940
• Windows + WSL2 (Ubuntu)
• WSL Codex app-server / CLI: 0.150.0-alpha.8
• App-server command line:

codex -c features.code_mode_host=true app-server --analytics-default-enabled

• CODEX_HOME used by the WSL app-server: Windows-side .codex directory mounted into WSL

Reproduction

• Existing Codex threads fail.
• Brand-new Codex threads also fail.
• A trivial prompt such as test fails before execution with:

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

• ChatGPT chat mode in the same desktop application works normally.
• ChatGPT/Codex in the web browser also works normally.

Read-only diagnostics

The persisted config.toml does not contain [mcp_servers.codex_app].

Using the exact bundled WSL Codex executable and the same CODEX_HOME:

CODEX_HOME="$codex_home" "$exe" mcp list

succeeds and lists the valid node_repl MCP server. There is no codex_app entry and no transport parse error in this direct CLI path.

Desktop logs show the failure specifically at thread/resume after other reads succeed (config/read, app/read, thread/read, model/list):

method=thread/resume
errorCode=-32600
failureReason=invalid_config
message="failed to load configuration: invalid transport\nin `mcp_servers.codex_app`\n"

The same failure repeats for multiple conversations.

Isolation tests

Tested one variable at a time, with full Desktop/app-server restart between tests:

• apps=true -> false: no effect
• plugins=true -> false: no effect
• enable_mcp_apps=false throughout

Feature flags were restored afterward:

• apps=true
• enable_mcp_apps=false
• plugins=true
• remote_plugin=true

No user-level [mcp_servers.codex_app] entry was added, and no .codex data was cleared.

Conclusion from this reproduction

The evidence is consistent with a Desktop-generated/effective runtime MCP entry being injected on the WSL thread/start / thread/resume path without a valid transport. The persisted config.toml itself parses successfully, so the current UI message telling the user to fix config.toml is misleading in this case.

I can provide additional redacted Desktop log excerpts if maintainers need them.

Independent reproduction with additional controls.

Environment:

• Microsoft Store package: OpenAI.Codex 26.820.7780.0
• Desktop app release: 26.820.60940
• Windows NT 10.0.26200 x64
• WSL2 Ubuntu 24.04
• Desktop-bundled Codex: 0.150.0-alpha.8
• [desktop] runCodexInWindowsSubsystemForLinux = true

Observed behavior:

• Desktop logs repeatedly report failed to load configuration: invalid transport in mcp_servers.codex_app for both thread/start and multiple thread/resume requests.
• The persisted user, default, and online TOML files contain no mcp_servers.codex_app entry.
• SQLite integrity checks currently pass, confirming that the mcp_servers.codex_app failure is independent of database corruption.
• Resetting Desktop caches, profile data, Settings/SystemAppData, and performing a full reinstall did not resolve the transport error.
• The standalone WSL CLI remains functional.

This supports the reported Desktop-to-WSL request-level MCP injection regression rather than persistent user configuration or SQLite corruption. The Windows-native workaround is not suitable here because the projects and toolchain need to remain in WSL.

Happy to test a corrected build.

Independent reproduction on the Microsoft Store build.

Environment:

• Codex Desktop package: OpenAI.Codex 26.820.7780.0
• Previous installed package: 26.818.5229.0
• Bundled Codex CLI: 0.150.0-alpha.8
• Windows + WSL2 Ubuntu

Observed:

• The failure reproduces after a full Desktop restart.
• It affects both creating a new thread and reopening an existing WSL-hosted thread.
• Exact error: failed to load configuration: invalid transport in mcp_servers.codex_app
• Switching the Agent Environment to Windows native makes threads work again, but the projects and toolchain need to remain in WSL.

Diagnostics:

• Neither the Windows-side nor WSL-side user config.toml contains mcp_servers.codex_app or a transport entry.
• The bundled codex-app-tools plugin injects codex_app.
• As a workaround test, I disabled codex-app-tools in user configuration. After restarting Desktop, the app automatically restored enabled = true, and the WSL error remained. The original configuration state is therefore already restored.

This started after the package change from 26.818.5229.0 to 26.820.7780.0; this is a temporal correlation, not proof that the update itself caused the regression.

No project-specific configuration is involved.

Same issue, using the integrated terminal in WSL mode has been broken for me for a week or so as well - feels like WSL support is an afterthought

I am getting this prompt: ChatGPT cannot load config.toml, so this conversation thread cannot continue. Please fix config.toml: invalid transport in mcp_servers.codex_app. It is frustrating as it stops me from working. Please fix this as soon as possible.

I found a workaround for this issue on Codex Desktop + WSL.

I was getting:

config.toml error: invalid transport for mcp_servers.codex_app

and couldn't open/resume my existing project chats in Codex Desktop.

Workaround

1. Keep WSL enabled in Codex Desktop. I did not disable runCodexInWindowsSubsystemForLinux.
2. Connect/sync your phone with Codex using Remote Control.
3. From the phone, open one of the affected project chats and wait until the conversation loads successfully on the phone.
4. Go back to Codex Desktop on the PC.
5. That chat should now be accessible from Desktop again.
6. Repeat the process from the phone for other affected project chats if necessary.

In my case, simply opening/loading the conversation once from the phone made it accessible again from Codex Desktop.

I did not need to modify mcp_servers.codex_app, disable WSL, or move my repositories out of WSL.

My projects are stored under WSL (/home/...), so disabling WSL was not a viable workaround for me.

This looks like opening the conversation through Remote Control causes some Codex app/session state to be initialized or refreshed, after which Desktop can resume the conversation normally.

I hope this helps others affected by the same regression.

Windows 11
Codex Desktop
WSL / Ubuntu
Projects stored inside /home/...
runCodexInWindowsSubsystemForLinux = true

Support, PLEASE, enable your speed!!!

You can downgrade to 26.818.8289.0 for now. Anything below this version breaks conversation paging. With this version, there are no WSL issues and any conversations started in 26.820.7780.0 still work as they should.

1. Download 26.818.8289.0 here (official OpenAI static/CDN link)
2. In PowerShell, remove newer Codex: Get-AppxPackage -Name OpenAI.Codex | Remove-AppxPackage
3. Install 26.818.8289.0: Add-AppxPackage -Path ".\ChatGPT-x64.msix"
4. Disable update check in Codex with check_for_update_on_startup = false in config.toml, otherwise it will update on its own
5. Optional: disable Microsoft Store updates if newly installed Codex appears there (either with a global toggle or by excluding OpenAI.Codex package from updates via MDM).

Verified WSL-preserving workaround for invalid transport in mcp_servers.codex_app

I reproduced this issue with:

• Windows 11
• Debian WSL2
• Codex Desktop UI version: 26.820.60940
• AppX package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• bundled WSL CLI: codex-cli 0.150.0-alpha.8
• runCodexInWindowsSubsystemForLinux = true

Both new and existing WSL threads failed with:

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

A community report in #40881 indicates that Desktop 26.820.9563.0 may contain a fix. Check for an official update first. If the error still occurs, the following temporary workaround restored WSL operation in my environment.

Temporary workaround

Fully close Codex Desktop.

Back up:

C:\Users\<USER>\.codex\config.toml

Add this user-level override:

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

Keep WSL execution enabled:

[desktop]
runCodexInWindowsSubsystemForLinux = true

Why this works:

• command = "/usr/bin/true" gives the MCP entry a syntactically valid local STDIO transport.
• enabled = false prevents the placeholder server from being used.
• WSL execution remains enabled.

This is a verified temporary workaround, not an official OpenAI fix or root-cause statement.

Limitation

Internal capabilities supplied specifically by the codex_app MCP server may be unavailable while this override is active.

Do not:

• replace or wrap the bundled binary under .codex\bin\wsl\...;
• hard-code the hash-named runtime directory;
• create a second [mcp_servers.codex_app] section;
• publish the complete config.toml, because it may contain private endpoints or credentials;
• remove the workaround solely because an update was installed.

Verification

Run this from Windows PowerShell to locate the current bundled WSL CLI dynamically:

$codexBinary = Get-ChildItem "$env:USERPROFILE\.codex\bin\wsl" -Recurse -File |
    Where-Object Name -eq "codex" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

if (-not $codexBinary) {
    throw "WSL Codex binary was not found."
}

$codexWslPath = (
    wsl.exe -d Debian -- wslpath -u "$($codexBinary.FullName)"
).Trim()

$codexHomeWsl = (
    wsl.exe -d Debian -- wslpath -u "$env:USERPROFILE\.codex"
).Trim()

Write-Host "Codex binary: $codexWslPath"
Write-Host "CODEX_HOME: $codexHomeWsl"

wsl.exe -d Debian -- env `
    "CODEX_HOME=$codexHomeWsl" `
    $codexWslPath mcp list

if ($LASTEXITCODE -ne 0) {
    throw "codex mcp list failed with exit code $LASTEXITCODE"
}

Expected codex_app row:

codex_app  /usr/bin/true  -  -  -  disabled  Unsupported

The exact spacing is not important. Unsupported in the Auth column is not the transport error.

After restarting Desktop, verify:

1. an existing WSL thread opens;
2. a new WSL thread can be created;
3. the intended WSL project opens;
4. temporary-file creation, reading, modification, restoration and deletion work inside a real /home/... Linux project.

Optional ChatGPT-assisted recovery prompt

If you want ChatGPT to guide the recovery, give it this prompt:

Codex Desktop on Windows 11 with WSL2 fails with:

invalid transport in `mcp_servers.codex_app`

Before changing anything:

1. Check the current official Codex documentation and determine whether a newer
   Desktop build fixes this issue.
2. Inspect only the relevant config.toml sections and do not expose secrets.
3. Create a timestamped backup before editing.
4. Recognize both [mcp_servers.codex_app] and
   [mcp_servers."codex_app"].
5. Refuse duplicate or conflicting codex_app sections.
6. If the section is absent, apply:

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

7. Preserve:

   [desktop]
   runCodexInWindowsSubsystemForLinux = true

8. Discover the current bundled WSL CLI dynamically.
9. Validate the result with codex mcp list and its exit code.
10. Do not replace files under .codex\bin\wsl.
11. After recovery, verify an existing thread, a new thread and a unique
    temporary-file write/read/modify/restore/delete test inside a real
    /home/... WSL project.
12. Clearly separate verified facts, inference and unknowns.

In my environment, the workaround was verified by:

• opening existing threads;
• creating new threads;
• accessing a real WSL project;
• creating, reading, modifying, restoring and deleting a temporary file under /home/...;
• confirming that the SHA-256 hash returned to its original value after adding and removing a space.

Official references:

• https://learn.chatgpt.com/docs/config-file/config-basic
• https://learn.chatgpt.com/docs/config-file/config-reference
• https://learn.chatgpt.com/docs/extend/mcp?surface=cli

Update: 26.820.9563.0 appears to fix codex_app transport error, but WSL project-path translation is now broken

After updating Codex Desktop to:

OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0

I no longer receive the previous:

invalid transport in mcp_servers.codex_app

error.

However, WSL sessions now fail with:

Invalid request: AbsolutePathBuf deserialized without a base path

I asked Codex to perform a read-only diagnostic of its inherited working directory. No files or state were modified.

The working directory received by Codex had this form:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0/app/resources/C:\home\<user>\projects\<project>

The expected WSL project path is:

/home/<user>/projects/<project>

The apparent failure is that Desktop supplies a Windows-form path:

C:\home\<user>\projects\<project>

to the WSL app-server without translating it to WSL path syntax.

The Windows path is then treated as a relative Unix path and appended beneath the app-server resources directory.

Additional diagnostics confirmed that the real WSL repository is healthy:

Expected project:
/home/<user>/projects/<project>

pwd -P after explicitly changing there:
/home/<user>/projects/<project>

git rev-parse --show-toplevel:
/home/<user>/projects/<project>

Explicitly changing directory to the correct /home/... path allows individual shell commands to execute, but it does not repair the inherited Desktop/app-server project path. Anything relying on the default working directory can still fail.

The WSL codex app-server itself is running from:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0/app/resources

So this appears to be a Desktop → WSL path-normalization regression:

Desktop project path:
C:\home\<user>\projects\<project>

Expected WSL translation:
/home/<user>/projects/<project>

Actual resolution:
<app resources>/C:\home\<user>\projects\<project>

That malformed path is also consistent with the new:

AbsolutePathBuf deserialized without a base path

error, since C:\... is not an absolute path under Unix/WSL path semantics.

The previous mcp_servers.codex_app failure appears resolved for me in 26.820.9563.0, but WSL execution is still blocked by this new path-handoff problem.

This regression has effectively made Codex unusable for my normal Windows + WSL workflow.

I am on Powered by Codex & OWL Version 26.820.60940 (released Aug 26, 2026). Setting:

[desktop]
runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "wsl"

does let affected threads resume, but it is not a real workaround for WSL users.
With the agent now running on Windows, my WSL-based skills and MCP servers no longer work correctly. They depend on Linux shell scripts, Linux paths, and the WSL runtime environment. Changing only the integrated terminal shell to wsl does not change where Codex itself launches skills/MCP processes.

So the choice is currently:

• Keep WSL execution enabled: existing threads cannot resume because of the invalid injected mcp_servers.codex_app config.
• Disable WSL execution: threads resume, but WSL-based skills and MCP integrations break.

That means this update breaks both continuation of existing work and the tooling needed for real WSL development. Asking users to switch the execution environment is not an acceptable workaround when it silently changes the runtime contract for their skills and MCP servers.

Please prioritize a fix for the WSL codex_app MCP injection path, and consider providing a supported rollback/version-pinning path for the Desktop app. Auto-updating into a release that disables a core development workflow is extremely disruptive.

### Update: 26.820.9563.0 appears to fix codex_app transport error, but WSL project-path translation is now broken

🤦

Read my comment for fix the bug: Workaround

I can reproduce what appears to be the same mcp_servers.codex_app failure on Windows, but without using the WSL execution path.

My setup uses an external/shared Codex App Server over WebSocket:

codex.exe app-server --listen ws://127.0.0.1:45789

Codex Desktop is then pointed at that shared App Server via:

CODEX_APP_SERVER_WS_URL=ws://127.0.0.1:45789

With the shared App Server running, Codex Desktop fails both when resuming an existing thread and when starting a new thread with:

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

Important observations:

• There is no [mcp_servers.codex_app] entry in my user config.toml.
• The failure happens during thread/resume / thread/start.
• New threads fail too, so this is not corrupted thread state.
• If I stop the shared WebSocket App Server and restart Codex Desktop so that it uses its normal built-in App Server, everything works again.
• Setting:

[desktop]
runCodexInWindowsSubsystemForLinux = false

does not solve this case, because this reproduction is not using the WSL execution path.

So there may be another affected path in addition to Desktop → WSL:

Codex Desktop
    ↓
external/shared WebSocket App Server
    ↓
thread/start or thread/resume
    ↓
invalid transport in mcp_servers.codex_app

This looks very similar to the request-level codex_app configuration issue described here, but I cannot yet confirm that the exact internal cause is identical.

It may be worth checking whether the Desktop-side codex_app MCP configuration injected into requests assumes that the App Server was launched and managed directly by Codex Desktop, and becomes incomplete when Desktop connects to an externally launched App Server.