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

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

Version 26.820.60940

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Stable app version

ChatGPT / Codex & OWL 26.820.60940
Released Aug 25, 2026
MSIX package version: OpenAI.Codex 26.820.7780.0

Working comparison version

ChatGPT (Beta) / Codex & OWL 26.727.40816
Released Jul 30, 2026

Platform

Windows 11 Home 10.0.26200 Build 26200, x64
Dell XPS 16 (Dell 16 Premium) DA16250
Intel Core Ultra 7 255H
32 GB RAM
WSL/Ubuntu workspace

Issue

Immediately after updating Stable to 26.820.60940, Codex Desktop can no longer start or resume chats in my WSL project.

The application displays:

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 same error occurs when creating a completely new chat, so this is not limited to existing thread state.

There is no [mcp_servers.codex_app] or [mcp_servers.codex_apps] entry in my user, system, or project TOML configuration.

I searched the active WSL config layers shown by /debug-config:

/etc/codex/config.toml
/home//.codex/config.toml
/home//Development/ETL - WSL/.codex/config.toml

and none contain codex_app or codex_apps.

I also tested:

features.apps = false

and disabled codex-app-tools; neither changes the error.

Important isolation tests

Standalone Codex CLI 0.145.0 inside WSL loads the same project successfully.
Stable Desktop bundles codex-cli 0.150.0-alpha.8.
I manually launched that exact bundled 0.150.0-alpha.8 executable against the same WSL workspace and it also starts successfully.
ChatGPT Beta 26.727.40816 works successfully with the same project/configuration.
Only ChatGPT Stable 26.820.60940 produces invalid transport in mcp_servers.codex_app.

This appears to indicate that Desktop 26.820.60940 is supplying or generating an invalid runtime MCP configuration when launching Codex, rather than the invalid configuration coming from config.toml.

Expected behavior

Stable should load the same workspace and configuration that Beta 26.727.40816 and standalone Codex successfully load.

What steps can reproduce the bug?

Stable app version

ChatGPT / Codex & OWL 26.820.60940
Released Aug 25, 2026
MSIX package version: OpenAI.Codex 26.820.7780.0

Working comparison version

ChatGPT (Beta) / Codex & OWL 26.727.40816
Released Jul 30, 2026

Platform

Windows 11 Home 10.0.26200 Build 26200, x64
Dell XPS 16 (Dell 16 Premium) DA16250
Intel Core Ultra 7 255H
32 GB RAM
WSL/Ubuntu workspace

Issue

Immediately after updating Stable to 26.820.60940, Codex Desktop can no longer start or resume chats in my WSL project.

The application displays:

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 same error occurs when creating a completely new chat, so this is not limited to existing thread state.

There is no [mcp_servers.codex_app] or [mcp_servers.codex_apps] entry in my user, system, or project TOML configuration.

I searched the active WSL config layers shown by /debug-config:

/etc/codex/config.toml
/home//.codex/config.toml
/home//Development/ETL - WSL/.codex/config.toml

and none contain codex_app or codex_apps.

I also tested:

features.apps = false

and disabled codex-app-tools; neither changes the error.

Important isolation tests

Standalone Codex CLI 0.145.0 inside WSL loads the same project successfully.
Stable Desktop bundles codex-cli 0.150.0-alpha.8.
I manually launched that exact bundled 0.150.0-alpha.8 executable against the same WSL workspace and it also starts successfully.
ChatGPT Beta 26.727.40816 works successfully with the same project/configuration.
Only ChatGPT Stable 26.820.60940 produces invalid transport in mcp_servers.codex_app.

This appears to indicate that Desktop 26.820.60940 is supplying or generating an invalid runtime MCP configuration when launching Codex, rather than the invalid configuration coming from config.toml.

Expected behavior

Stable should load the same workspace and configuration that Beta 26.727.40816 and standalone Codex successfully load.

What is the expected behavior?

It works. Threads load.

Additional information

No response

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

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

Setting the plugin to enabled = false alone did not stop the bundled MCP contribution from being merged; thread/start still failed with invalid transport.
codex plugin remove codex-app-tools@openai-bundled removed the bad contribution and a direct app-server thread/start succeeded.
On the next Desktop launch, bundled-plugin reconciliation automatically reinstalled and re-enabled codex-app-tools, and the failure returned.
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.

@future3OOO

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

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

This brought it back.
Many thanks @future3OOO

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:

a public acknowledgement that the incident is known and triaged;
a short status on whether a hotfix or rollback is being worked on;
official guidance for affected WSL users that does not require unsupported hacks;
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:

thread/resume with Desktop's flat override below reproduced -32600 / invalid transport:
```
{
  "config": {
    "mcp_servers.codex_app.enabled_tools": ["x"]
  }
}
```
The same resume without that leaf override succeeded.
The same resume with the leaf override and a complete user-level codex_app stdio definition succeeded.
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

@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: #40715 (comment)

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.

Additional confirmed affected user from Taiwan.

I am a paid ChatGPT subscriber in Taiwan, and this Windows + WSL regression has blocked my Codex App workflow for several days.

Environment

Region / Microsoft Store market: Taiwan
Windows 11 x64
Codex App internal version: 26.820.60940
Microsoft Store / MSIX package: OpenAI.Codex 26.820.7780.0
Agent environment: WSL2

Both creating a new WSL conversation and resuming an existing WSL conversation fail with:

failed to load configuration: invalid transport in mcp_servers.codex_app

My original user/project config.toml does not define [mcp_servers.codex_app]. All temporary configuration experiments have been removed, the original configuration has been restored, and no local workaround is currently active.

As of August 28, 2026, the Taiwan Microsoft Store has not offered the reported candidate replacement package 26.820.9563.0; the available package remains 26.820.7780.0.

Please count this as an affected Taiwan rollout and confirm:

Which Codex App/MSIX version is the intended fix for Windows x64 + WSL2.
Whether that fixed package is being rolled out to the Taiwan Microsoft Store.
Whether any action is required beyond waiting for the Store update.

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Reproduced environment

Source of the injected server

Isolation results

Workaround impact

Requested fix

47 remaining items

Independent confirmation and WSL-native workaround

Deterministic request-level confirmation

WSL-native workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

andreidita22 commented on Aug 25, 2026

movrren commented on Aug 25, 2026

itsnoahvandal commented on Aug 25, 2026

tharak123455 commented on Aug 25, 2026

SoymilkWinsAgain commented on Aug 25, 2026

NERDHEAD-lab commented on Aug 25, 2026

TrinityLGG commented on Aug 25, 2026

future3OOO commented on Aug 25, 2026

Reproduced environment

Source of the injected server

Isolation results

Workaround impact

Requested fix

Wrong999 commented on Aug 25, 2026

movrren commented on Aug 25, 2026

47 remaining items

taobaibais commented on Aug 26, 2026

sXe79 commented on Aug 26, 2026

kushkatech commented on Aug 26, 2026

taobaibais commented on Aug 26, 2026

MisterRound commented on Aug 26, 2026

Independent confirmation and WSL-native workaround

Deterministic request-level confirmation

WSL-native workaround

etraut-openai commented on Aug 26, 2026

AetheraSoftware commented on Aug 27, 2026

warengonzaga commented on Aug 27, 2026

proxypanther commented on Aug 27, 2026

youngcs1024 commented on Aug 27, 2026

warengonzaga commented on Aug 27, 2026

mtk177a commented on Aug 27, 2026

itsnoahvandal commented on Aug 27, 2026

DesignMike commented on Aug 27, 2026

JT-TPE commented on Aug 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions