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

Environment

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

Problem

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

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

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

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

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

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

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

Notes:

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

Workaround

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

Expected fix

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

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

[Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works #40715
[Windows][WSL] All threads fail with invalid transport in mcp_servers.codex_app after update to 26.820.x — WSL app-server stuck at 0.150.0-alpha.8 #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.

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

Keep WSL enabled in Codex Desktop. I did not disable runCodexInWindowsSubsystemForLinux.
Connect/sync your phone with Codex using Remote Control.
From the phone, open one of the affected project chats and wait until the conversation loads successfully on the phone.
Go back to Codex Desktop on the PC.
That chat should now be accessible from Desktop again.
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.

Download 26.818.8289.0 here (official OpenAI static/CDN link)
In PowerShell, remove newer Codex: Get-AppxPackage -Name OpenAI.Codex | Remove-AppxPackage
Install 26.818.8289.0: Add-AppxPackage -Path ".\ChatGPT-x64.msix"
Disable update check in Codex with check_for_update_on_startup = false in config.toml, otherwise it will update on its own
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:

an existing WSL thread opens;
a new WSL thread can be created;
the intended WSL project opens;
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:

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.

Positive newer-version data point from Windows + WSL, following earlier use of a local workaround for this issue.

I previously had the invalid transport in mcp_servers.codex_app WSL problem and had worked around it locally with:

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

There was also a separate SQLite migration-checksum problem in the same profile. After diagnosing and repairing that separately (CRLF/LF _sqlx_migrations.checksum mismatch; details posted on #38528), I retested the current Desktop build without the codex_app workaround.

Current environment:

Codex Desktop 26.825.6671.0
bundled WSL runtime codex-cli 0.151.0-alpha.7.2
WSL2 Ubuntu
[desktop] runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"
[plugins."codex-app-tools@openai-bundled"] enabled = true
no [mcp_servers.codex_app] override in config.toml

With that configuration, Desktop starts successfully and actual WSL turns are working. I tested shell commands plus file create/delete operations and the Desktop Review/diff UI. The previous invalid transport in mcp_servers.codex_app error has not returned.

So, at least on 26.825.6671.0 + 0.151.0-alpha.7.2, I no longer need the /bin/false workaround that was necessary on the affected older build.

I would not take one machine as proof that the issue is universally fixed, but this may help identify the build range where behavior changed. Also worth emphasizing that the SQLite startup failure and the codex_app transport failure were separate problems in this profile; repairing the SQLite migration metadata did not itself constitute a fix for the MCP transport bug.

This comment was written with assistance from ChatGPT after an interactive diagnostic session; the commands, outputs, A/B tests, and final recovery were run and verified on the affected machine by the user.

Navigation Menu

Repository navigation

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

Environment

Problem

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

Workaround

Expected fix

40 remaining items

Environment

Reproduction

Read-only diagnostics

Isolation tests

Conclusion from this reproduction

Workaround

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

Temporary workaround

Limitation

Verification

Optional ChatGPT-assisted recovery prompt

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

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Environment

Problem

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

Workaround

Expected fix

Activity

github-actions commented on Aug 26, 2026

Mykybo commented on Aug 26, 2026

habaneraa commented on Aug 26, 2026

ajain950 commented on Aug 26, 2026

shuangyu233 commented on Aug 26, 2026

JojoRoro commented on Aug 26, 2026

Yuchees commented on Aug 26, 2026

ansedo commented on Aug 26, 2026

liuhaoqiu commented on Aug 26, 2026

fbernklau commented on Aug 26, 2026

40 remaining items

xuxiushan commented on Aug 26, 2026

Environment

Reproduction

Read-only diagnostics

Isolation tests

Conclusion from this reproduction

JimGaune commented on Aug 27, 2026

VictorCastro04 commented on Aug 27, 2026

thekevinc commented on Aug 27, 2026

sdp0825 commented on Aug 27, 2026

GeorgeValle commented on Aug 27, 2026

Workaround

alibekkrona commented on Aug 27, 2026

fenny-org commented on Aug 27, 2026

alibekkrona commented on Aug 27, 2026

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

Temporary workaround

Limitation

Verification

Optional ChatGPT-assisted recovery prompt

BobSanDiego commented on Aug 27, 2026

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

isaacwu-eis commented on Aug 27, 2026

tminich commented on Aug 27, 2026

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

GeorgeValle commented on Aug 27, 2026

beifangzhishi-ops commented on Aug 27, 2026

Shad0wWulf commented on Aug 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

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

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