Codex Desktop fails to create new chats in WSL mode: invalid transport in `mcp_servers.codex_app`

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

• #40819
• #40715
• #40829
• #40732

Powered by Codex Action

after update:

<img width="728" height="166" alt="Image" src="https://github.com/user-attachments/assets/a8bbff27-2420-4ecb-ba79-a5c458dad013" />

Same issue here

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

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

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

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

### Symptom

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

> ChatGPT can't load config.toml, so this thread can't resume.
> Fix config.toml: invalid transport in mcp_servers.codex_app.
> After saving the file, reopen the thread.

### What I found

On my machine, the active Windows config was:

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

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

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

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

### Workaround

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

PowerShell:

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

Copy-Item $Config $Backup

@"

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

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

  ### Verification

  Run:
PowerShell:

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

  & $CodexExe mcp list

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

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

### Dev-team lead

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

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.

I reproduced this on Codex Desktop 26.820.7780.0, Windows x64, Ubuntu 24.04 WSL2, with bundled codex-cli 0.150.0-alpha.8.

Confirmed root cause

Desktop injects an incomplete runtime configuration similar to:

mcp_servers.codex_app.enabled_tools = ["..."]

but does not provide either command or url. The CLI therefore cannot determine the MCP transport and rejects the entire request with:

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

I reproduced this independently:

codex \
  -c 'mcp_servers.codex_app.enabled_tools=["x"]' \
  mcp list

Result:

invalid transport in `mcp_servers.codex_app`

Adding a valid command and args makes the same configuration pass validation.

Temporary workaround

The following explicit user-level override restored WSL startup for me:

[desktop]
integratedTerminalShell = "wsl"
runCodexInWindowsSubsystemForLinux = true

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

[mcp_servers.codex_app]
command = "/bin/sh"
args = [
  "/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/codex-app-tools/0.1.3/scripts/launch_codex_app_tools_mcp",
  "/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/codex-app-tools/0.1.3/server.mjs"
]
startup_timeout_sec = 10
tool_timeout_sec = 3600

After a full Desktop restart, codex mcp list inside WSL reported codex_app as enabled with /bin/sh, and new WSL-native tasks could be created.

This is only a workaround. It hard-codes the current bundled plugin version and may break after a plugin update.

Additional WSL path regressions after applying the workaround

WSL starts, but existing tasks created in Windows-native mode still fail with:

Invalid request: AbsolutePathBuf deserialized without a base path

The Desktop log shows a malformed mixed Windows/WSL path:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0/app/resources/C:\Users\<user>\Documents\Codex

Desktop appears to treat the saved Windows cwd as a relative path and prepend the application resources directory.

Creating a new project/task with a native WSL cwd such as:

/opt/git/chats-without-project

works. The old task is not repaired automatically.

Pasted screenshots have the same bridge problem. Desktop creates the PNG successfully, but passes it to the WSL agent as:

C:\Users\<short-user-name>\AppData\Local\Temp\codex-clipboard-....png

The agent reports No such file or directory, although the image is readable at:

/mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-....png

Manual path conversion works.

Bubblewrap mismatch

The updated WSL CLI also rejected the older staged bwrap:

bundled bubblewrap digest mismatch
expected: 77360cb751ccedc5971391444ac86a8a33c15b04d6b4a6fe45f5d25496e62c4c
got:      067a1289020a7398e71cf0cebbb057277b792831735da080f6cd88b8ec1237fa

Installing Ubuntu's system package restored sandboxed commands:

apt-get install -y bubblewrap

Suggested product fixes

1. Inject the complete codex_app transport (command or url) before app-server configuration validation.
2. Normalize every Desktop-originated path according to the target host before serializing it as AbsolutePathBuf.
3. Detect tasks created under a different execution environment and migrate or reject their cwd with an actionable message.
4. Convert Windows clipboard-image paths to /mnt/<drive>/..., or copy the image bytes into a Codex-owned WSL-accessible cache.
5. Stage the WSL CLI and its matching codex-resources/bwrap atomically during updates.

I reproduced this on Codex Desktop 26.820.7780.0 with WSL and traced the Desktop -> WSL app-server JSON-RPC traffic. This appears to be the same bug as #40894, but I was able to isolate the failing payload.

During thread/resume, Desktop injects a flat config override like:

"mcp_servers.codex_app.enabled_tools": [ ... ]

but no corresponding mcp_servers.codex_app.command or mcp_servers.codex_app.url is present. The app-server therefore materializes codex_app as an MCP server without a resolvable transport and fails with:

invalid transport in mcp_servers.codex_app

I confirmed this by placing a Linux wrapper in front of the bundled WSL app-server (codex-cli 0.150.0-alpha.8) and filtering mcp_servers.codex_app.* from the incoming JSON-RPC before forwarding it to the real binary. With that injected override removed, the affected task opens successfully.

Additional WSL detail: the Desktop app-server runs in a different mount namespace from the user's interactive WSL shell, so the test wrapper had to be bind-mounted into the app-server namespace using nsenter -t <PID> -m.

Feedback ID: 01a0104e-ffed-74d1-9278-34af2907b2d2

Full diagnostic report: #40894

This strongly points to the Desktop -> WSL thread/resume config injection path, specifically injecting mcp_servers.codex_app.enabled_tools without a complete MCP transport definition.

Temporary WSL workaround that worked for me

This is not an official fix. It is a temporary workaround until the Desktop -> WSL config injection bug is fixed. Use at your own risk and remove it once an official build resolves the issue.

The workaround has two parts:

1. A small Go wrapper that sits in front of the bundled WSL codex app-server and removes mcp_servers.codex_app.* from incoming JSON-RPC before forwarding it to the real bundled Codex binary.
2. A Bash helper that detects the active Desktop app-server, bind-mounts the wrapper into that process' mount namespace, wires codex-code-mode-host, validates the mount, and restarts the app-server.

The reason nsenter is needed is that Codex Desktop launches the WSL app-server in a different mount namespace from the normal interactive WSL shell.

---

1. Go wrapper

Save as:

/home/<user>/codex-wrapper.go

Example used on my machine (/home/rodrigo/...):

package main

import (
    "bufio"
    "encoding/json"
    "fmt"
    "io"
    "os"
    "os/exec"
    "strings"
)

const realCodex = "/home/rodrigo/codex-desktop-real"

const inputLog = "/tmp/codex-desktop-input.log"
const outputLog = "/tmp/codex-desktop-output.log"

func writeLog(path string, data []byte) {
    f, err := os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
    if err != nil {
        fmt.Fprintf(os.Stderr, "[codex-wrapper] error opening %s: %v\n", path, err)
        return
    }
    defer f.Close()

    _, _ = f.Write(data)
    _, _ = f.Write([]byte("\n"))
}

func clean(v interface{}) {
    switch x := v.(type) {
    case map[string]interface{}:
        // Actual flat format observed from Desktop, e.g.
        // "mcp_servers.codex_app.enabled_tools": [...]
        for key := range x {
            if key == "mcp_servers.codex_app" ||
                key == "mcp_servers.codex_apps" ||
                strings.HasPrefix(key, "mcp_servers.codex_app.") ||
                strings.HasPrefix(key, "mcp_servers.codex_apps.") {

                delete(x, key)
                fmt.Fprintf(os.Stderr, "[codex-wrapper] removed invalid override: %s\n", key)
            }
        }

        // Defensive handling for an eventually nested snake_case shape.
        if raw, exists := x["mcp_servers"]; exists {
            if servers, ok := raw.(map[string]interface{}); ok {
                for _, key := range []string{"codex_app", "codex_apps"} {
                    if _, exists := servers[key]; exists {
                        delete(servers, key)
                        fmt.Fprintf(os.Stderr, "[codex-wrapper] removed nested MCP: %s\n", key)
                    }
                }
            }
        }

        // Defensive handling for an eventually nested camelCase shape.
        if raw, exists := x["mcpServers"]; exists {
            if servers, ok := raw.(map[string]interface{}); ok {
                for _, key := range []string{"codexApp", "codexApps"} {
                    if _, exists := servers[key]; exists {
                        delete(servers, key)
                        fmt.Fprintf(os.Stderr, "[codex-wrapper] removed camelCase MCP: %s\n", key)
                    }
                }
            }
        }

        for _, child := range x {
            clean(child)
        }

    case []interface{}:
        for _, child := range x {
            clean(child)
        }
    }
}

func filterInput(dst io.Writer, src io.Reader) error {
    scanner := bufio.NewScanner(src)
    buffer := make([]byte, 64*1024)
    scanner.Buffer(buffer, 64*1024*1024)

    writer := bufio.NewWriter(dst)
    defer writer.Flush()

    for scanner.Scan() {
        line := append([]byte(nil), scanner.Bytes()...)
        writeLog(inputLog, line)

        var data interface{}
        if err := json.Unmarshal(line, &data); err != nil {
            writeLog(outputLog, line)
            if _, err := writer.Write(line); err != nil {
                return err
            }
            if err := writer.WriteByte('\n'); err != nil {
                return err
            }
            if err := writer.Flush(); err != nil {
                return err
            }
            continue
        }

        clean(data)

        out, err := json.Marshal(data)
        if err != nil {
            return err
        }

        writeLog(outputLog, out)

        if _, err := writer.Write(out); err != nil {
            return err
        }
        if err := writer.WriteByte('\n'); err != nil {
            return err
        }
        if err := writer.Flush(); err != nil {
            return err
        }
    }

    return scanner.Err()
}

func main() {
    if _, err := os.Stat(realCodex); err != nil {
        fmt.Fprintf(os.Stderr, "[codex-wrapper] real Codex not found: %s\n", realCodex)
        os.Exit(1)
    }

    cmd := exec.Command(realCodex, os.Args[1:]...)
    cmd.Env = os.Environ()
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    stdin, err := cmd.StdinPipe()
    if err != nil {
        fmt.Fprintln(os.Stderr, "[codex-wrapper] StdinPipe:", err)
        os.Exit(1)
    }

    if err := cmd.Start(); err != nil {
        fmt.Fprintln(os.Stderr, "[codex-wrapper] Start:", err)
        os.Exit(1)
    }

    go func() {
        if err := filterInput(stdin, os.Stdin); err != nil {
            fmt.Fprintln(os.Stderr, "[codex-wrapper] stdin filter:", err)
        }
        _ = stdin.Close()
    }()

    if err := cmd.Wait(); err != nil {
        if exitErr, ok := err.(*exec.ExitError); ok {
            os.Exit(exitErr.ExitCode())
        }
        fmt.Fprintln(os.Stderr, "[codex-wrapper] Wait:", err)
        os.Exit(1)
    }
}

Compile it in WSL:

sudo apt update
sudo apt install -y golang-go

go build -o /home/rodrigo/codex-wrapper /home/rodrigo/codex-wrapper.go
chmod +x /home/rodrigo/codex-wrapper

Before using the wrapper, copy the real bundled Desktop Codex binary somewhere outside the runtime directory. On my machine:

PID=$(pgrep -f 'codex.*app-server' | head -1)
CODEX_PATH=$(tr '\0' ' ' < /proc/$PID/cmdline | awk '{print $1}')

cp "$CODEX_PATH" /home/rodrigo/codex-desktop-real
chmod +x /home/rodrigo/codex-desktop-real

The real binary resolves codex-code-mode-host relative to its own location, so I also created:

RUNTIME_DIR=$(dirname "$CODEX_PATH")
ln -sf "$RUNTIME_DIR/codex-code-mode-host" /home/rodrigo/codex-code-mode-host

---

2. Helper script

Save as:

/home/rodrigo/fix-codex-transport.sh

#!/usr/bin/env bash
set -euo pipefail

WRAPPER="/home/rodrigo/codex-wrapper"
CODE_MODE_LINK="/home/rodrigo/codex-code-mode-host"

PID="$(pgrep -f '/mnt/c/Users/.*/.codex/bin/wsl/.*/codex.*app-server' | head -1 || true)"

if [ -z "$PID" ]; then
    echo "No Codex app-server found. Open Codex Desktop first."
    exit 1
fi

CODEX_PATH="$(tr '\0' ' ' < /proc/$PID/cmdline | awk '{print $1}')"
RUNTIME_DIR="$(dirname "$CODEX_PATH")"
CODE_MODE_HOST="$RUNTIME_DIR/codex-code-mode-host"

echo "PID: $PID"
echo "Runtime: $RUNTIME_DIR"

if [ ! -f "$WRAPPER" ]; then
    echo "ERROR: wrapper not found: $WRAPPER"
    exit 1
fi

if [ ! -f "$CODE_MODE_HOST" ]; then
    echo "ERROR: codex-code-mode-host not found: $CODE_MODE_HOST"
    exit 1
fi

chmod +x "$WRAPPER"
chmod +x "$CODE_MODE_HOST"
ln -sf "$CODE_MODE_HOST" "$CODE_MODE_LINK"

echo "Applying wrapper inside Codex app-server mount namespace..."

sudo nsenter -t "$PID" -m -- mount --bind \
    "$WRAPPER" \
    "$CODEX_PATH"

WRAPPER_HASH="$(sha256sum "$WRAPPER" | awk '{print $1}')"
MOUNT_HASH="$(sudo nsenter -t "$PID" -m -- sha256sum "$CODEX_PATH" | awk '{print $1}')"

echo "Wrapper: $WRAPPER_HASH"
echo "Runtime: $MOUNT_HASH"

if [ "$WRAPPER_HASH" != "$MOUNT_HASH" ]; then
    echo "ERROR: bind mount was not applied correctly."
    exit 1
fi

echo "Wrapper mounted successfully. Restarting current app-server..."
kill "$PID" 2>/dev/null || true

echo
 echo "Temporary Codex workaround applied. Reopen the task in Codex Desktop."

Make it executable and optionally add a short command:

chmod +x /home/rodrigo/fix-codex-transport.sh
sudo ln -sf /home/rodrigo/fix-codex-transport.sh /usr/local/bin/fix-codex-transport

Then when the error returns:

fix-codex-transport

Important caveat

The bind mount is tied to the WSL mount namespace used by the Desktop app-server. If Desktop creates a fresh app-server in a fresh namespace, or after a restart/update/reboot, the workaround may need to be applied again. The runtime hash directory can also change after an update, which is why the Bash helper derives the active CODEX_PATH dynamically from the running process instead of hard-coding the runtime hash.

Why this works

In my trace, the incoming thread/resume JSON contained:

mcp_servers.codex_app.enabled_tools

The wrapper removes mcp_servers.codex_app.* before the request reaches the real bundled app-server. After doing this, the previously failing task opened successfully.

Again: this is only a temporary diagnostic/workaround. The proper fix should be in Codex Desktop's WSL config injection path.

<img width="568" height="157" alt="Image" src="https://github.com/user-attachments/assets/308dddbe-bf65-4851-93be-c9ed278445cd" />

I have the exact same issue. All my projects are on WSL, so I cannot turn off the WSL option.

Another affected WSL user here. With this many independent reproductions and related issues, can someone from OpenAI please confirm that this regression has been seen and triaged? There still appears to be no maintainer acknowledgement, which is frustrating for users who cannot simply switch their development environment to native Windows.

I'm getting the same error with the same setup. Seems to be universal.

exactly same issue

It appears that this is a bug affecting all users who have updated Codex and are using it in WSL.

same for me !!

what a shit codex

I am not going to update this shit anymore, what kind update is that!

Same over here, and that workaround above did not work.

For a temporary fix until the issue is resolved, maybe download the previous version from Uptodown and use that.

Additional confirmation from another affected Windows/WSL environment.

Environment

• Codex Desktop: 26.820.7780.0
• Bundled WSL app-server: 0.150.0-alpha.8
• Windows x64
• WSL2
• Ubuntu 24.04
• Bundled codex-app-tools: 0.1.3

Observed behavior

Both new chat creation and existing thread resume fail when the Agent Environment is set to WSL:

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

Desktop logs record the failure as:

errorCode=-32600
failureReason=invalid_config
method=thread/start

The same error also occurs with method=thread/resume.

The failure is independent of the working directory. It occurred with:

• /home/<user>/workspace/...
• /mnt/c/Users/<user>/...
• ~

Regression evidence

WSL mode worked before the update:

• Codex Desktop 26.818.8289.0
• WSL app-server 0.149.0-alpha.4.3
• thread/resume completed with errorCode=null on 2026-08-25

After updating:

• Codex Desktop 26.820.7780.0
• WSL app-server 0.150.0-alpha.8
• thread/start and thread/resume consistently fail with invalid_config on 2026-08-27

Additional diagnostics

• Running Codex directly inside WSL works normally.
• codex mcp list succeeds.
• Neither the Windows nor WSL user config.toml contains an [mcp_servers.codex_app] section or a transport key.
• Switching the Agent Environment back to Windows makes chat creation work again.
• The cached codex-app-tools desktop-mcp.json is byte-for-byte identical to the version bundled with the desktop app.
• Passing an equivalent codex_app MCP definition directly to the bundled WSL CLI parses successfully.

This strongly suggests a regression in the Windows Desktop → WSL thread/start / thread/resume path while constructing, translating, or injecting the internal mcp_servers.codex_app configuration. It does not appear to be caused by the user’s config.toml.

Same issue here

Can temporarily fix the issue by downgrading to this version:
https://github.com/Wangnov/codex-app-mirror/releases/tag/codex-app-26.818.61809

Same issue here.

Same issue. Have not tried workarounds yet

"1. 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.\"

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

Update: this issue appears to be fixed after updating Codex Desktop to 26.820.9563.0.

With the Agent Environment set to WSL, I can now create new tasks and resume existing tasks normally. The following error no longer occurs:

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

I did not modify either the Windows or WSL config.toml, so the resolution appears to have come from the Codex Desktop update.

Environment:

• Codex Desktop: 26.820.9563.0
• Windows x64
• WSL2
• Ubuntu 24.04

Thank you for the fix.

having the same exact issue... any fix to this to work in wsl2? not able to use codex at all here.

Please see my comment for downgrade instructions.

The bug is simple to fix temporarily, just read my comment: Workaround