Codex Desktop: invalid transport in mcp_servers.codex_app although codex_app is not present in config.toml

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

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

Powered by Codex Action

I have the same issue as well

After updating the Codex desktop app, an existing thread cannot resume.

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

My config.toml contains no [mcp_servers.codex_app] section. It only
contains the app-generated mcp_servers.node_repl configuration.
Therefore codex_app appears to be injected by the updated desktop
runtime or bundled OpenAI app tooling.

App version reported in the generated environment:
26.820.60940

Windows host with Codex running through WSL.

Yes, I have the same issue and I can't work at all. Has anybody figured out a workaround for this? Because I can't use Codex at all. it won't let me do anything. Do we have a timeline for a fix? Perhaps it is time for their DevOps engineers too roll back this latest release.

<img width="536" height="135" alt="Image" src="https://github.com/user-attachments/assets/0e235b17-c33c-45ee-bc5a-570619250fa1" />

same this broke for me . please fix urgently . looks like codex cli still works

Same issue here with the existing threads, also unable to start new tasks.

Windows Codex app: 26.820.7780.0
WSL Codex CLI: 0.149.1
Bundled plugin: codex-app-tools 0.1.3

All existing and new desktop chats fail with:
failed to load configuration:
invalid transport in mcp_servers.codex_app

WSL codex mcp list succeeds.
Plugin cache was regenerated and produced an identical manifest.
A reversible removal of codex_app from the cached manifest did not unblock the app.

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

Have the same issue; version 26.820.60940

Same issue here on macOS after today's Codex app update.

• Codex app version: 26.819.11345
• Existing threads fail with:

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

• Creating a new chat also fails with:

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

• ~/.codex/config.toml does not contain any codex_app entry:

grep -n -C 3 'codex_app' ~/.codex/config.toml
returns no output.

• The bundled CLI is present and reports:

codex-cli 0.150.0-alpha.8

This looks like mcp_servers.codex_app is being injected by the desktop app/runtime rather than coming from the user's config.toml.

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 mcp_servers.codex_app 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 chats from starting or resuming should not consume users' paid usage window without remedy.

Additional macOS reproduction with a strong same-machine / same-account A/B control:

Environment

• macOS 26.6.2, Apple Silicon (arm64)
• ChatGPT Desktop: 26.820.60940 (build 7119)
• Bundled Codex runtime: codex-cli 0.150.0-alpha.8

Exact failure

Every new Codex conversation fails immediately with:

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

Key isolation result

This Mac has two macOS user accounts. Using the same physical Mac, the same /Applications/ChatGPT.app binary, and the same ChatGPT account:

• macOS user A: Codex Desktop works normally
• macOS user B: every new conversation fails with invalid transport in mcp_servers.codex_app

The failing macOS user appears to have hit the error during its first Codex/Desktop initialization.

Ruled out on the failing macOS user

• Brand-new empty workspace/folder reproduces the failure, so it is not project/repo-specific.
• ~/.codex/config.toml contains no mcp_servers.codex_app entry.
• codex mcp list succeeds with the bundled CLI.
• The ChatGPT app bundle passes codesign --verify --deep --strict.
• Resetting Desktop user state did not help, including Codex-related Application Support / Preferences / caches / HTTP storage.
• Resetting .codex-global-state.json and Codex Apps tool cache did not help.
• Moving the entire ~/.codex directory away and allowing Desktop to recreate it from scratch still reproduces the same error.

Additional observation

Runtime logs show the internal codex_apps plugin runtime can initialize successfully, while thread creation still fails with the singular mcp_servers.codex_app invalid-transport error. This supports the theory that the failing entry is generated/injected by Desktop at thread start rather than coming from the user's TOML.

Why this case may be useful

Because one macOS user works and another fails on the same Mac/app/account, this looks like a per-macOS-user Desktop first-run/bootstrap/runtime injection issue, not a damaged app binary, user TOML, project configuration, or ChatGPT account entitlement.

A likely regression test would be: create a fresh macOS user profile, launch this Desktop build, complete first-run Codex initialization, and start a new thread. The generated/injected mcp_servers.codex_app entry should always include a valid transport (or be omitted).

The volume of reports around mcp_servers.codex_app now makes it clear this is not an isolated local configuration problem. Could an OpenAI maintainer please acknowledge the incident and clarify whether it is under active investigation? A public status note would prevent affected users from wasting more time modifying clean configs or trying unsafe workarounds.

<img width="568" height="157" alt="Image" src="https://github.com/user-attachments/assets/701560e4-c622-4d51-b6df-41709e167e76" />

I have the exact same issue after updating to v26.820.60940.

same issue here, is there any fix that doesnt involve stopping using WSL?

+1 started today

<img width="662" height="139" alt="Image" src="https://github.com/user-attachments/assets/f3432892-3362-44a7-bb06-6f6596bce3b1" />

Version 26.820.60940

Windows (WSL mode)

same issue here, is there any fix that doesnt involve stopping using WSL?

see: https://github.com/openai/codex/issues/40881#issuecomment-5426672277

🎉 Hooray — I finally found it and confirmed the workaround!

The problem was not caused by my project or by config.toml. It was a multi-user macOS permissions problem in Codex Desktop.

Root cause

Codex Desktop uses this global directory for internal Unix sockets:

/private/tmp/codex-browser-use

The directory had been created by another macOS user with mode 0755. Therefore, the affected user could traverse and read the directory but could not create a new socket inside it.

The first relevant error in the logs was:

Failed to start the Codex app tools native pipe
listen EACCES: permission denied /tmp/codex-browser-use/<uuid>.sock

Approximately seven seconds later, Codex reported the misleading secondary error:

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

What fixed it

I changed only the permissions of this exact temporary directory:

sudo chmod 1777 /private/tmp/codex-browser-use

I did not use -R.

After fully restarting Codex under the affected macOS account, existing threads resumed successfully and new threads could be created again. ✅

No changes to config.toml, MCP definitions, plugins, AGENTS.md, project files, or Codex executables were needed.

Mode 1777 is the standard sticky-directory pattern used for shared temporary directories. It allows each user to create their own files while preventing users from deleting files owned by someone else.

How I investigated it

I used the second, working macOS account as a control and performed a read-only comparison.

1. I audited the available user and project configuration files:

• ~/.codex/config.toml
• project .codex/config.toml
• AGENTS.md
• the bundled codex-app-tools/desktop-mcp.json

1. I confirmed that no available config.toml contained:

``toml
[mcp_servers.codex_app]
``

1. I verified that the bundled plugin manifest contained a valid STDIO transport with command, args, and cwd.

1. I compared checksums of the plugin manifest, launcher, server, and related cache files between the working and failing macOS users. They were identical, ruling out a corrupted plugin installation.

1. I searched the desktop logs for:

``text
invalid transport
mcp_servers.codex_app
Failed to start the Codex app tools native pipe
EACCES
codex-browser-use
``

1. I reconstructed the update timeline:

• Build 26.818.41705 was working.
• Codex updated and restarted into build 26.820.60940.
• The new build immediately failed to create the app-tools socket.
• A few seconds later, every thread failed with invalid transport.

1. I inspected the directory ownership and permissions with commands such as:

``bash
ls -ldeO@ /private/tmp/codex-browser-use
stat -f '%N owner=%Su group=%Sg mode=%Sp' /private/tmp/codex-browser-use
id
``

1. I inspected the packaged application code in app.asar and found that the Unix path is hardcoded as:

``text
/tmp/codex-browser-use
``

The application calls recursive directory creation, but if the directory already exists, it does not validate or correct its owner or permissions.

1. The app catches the socket startup failure and does not set CODEX_APP_TOOLS_PIPE_PATH. The observed behavior strongly suggests that a partial mcp_servers.codex_app override is then processed without a valid command or url, producing the secondary invalid transport error.

I avoided reading auth.json, tokens, credentials, cookies, or unrelated project source files. Log excerpts were sanitized before inspection.

Reproduction scenario

1. Log into macOS user A and start Codex.
2. Codex creates /tmp/codex-browser-use, owned by user A with mode 0755.
3. Leave the directory in place.
4. Log into macOS user B and start Codex.
5. User B cannot bind a socket inside the directory.
6. Codex reports invalid transport in mcp_servers.codex_app.

Notes for Windows and WSL users

⚠️ The chmod 1777 workaround is specifically for macOS or another Unix environment using /tmp. Do not run it on native Windows.

The packaged application uses a Windows named-pipe path similar to:

\\.\pipe\codex-browser-use

Therefore, the same visible mcp_servers.codex_app error on Windows may have a different underlying cause.

In particular, Windows with WSL may involve:

• the desktop app running on Windows while the app-server runs inside WSL;
• Windows and Unix launcher-path translation;
• different CODEX_HOME locations;
• the internal codex_app configuration being injected into a different environment;
• a partial runtime override containing enabled_tools but no command or url.

A related Windows/WSL report is:

https://github.com/openai/codex/issues/40881

For Windows/WSL, I would first check the logs for the error that occurs immediately before invalid transport, verify whether the native pipe starts, and inspect the effective runtime configuration passed from Desktop to the WSL app-server. The macOS directory-permission workaround should not be assumed to apply there.

Suggested upstream fix

• Use a per-user socket directory, for example:

``text
$TMPDIR/codex-browser-use
``

or:

``text
/tmp/codex-browser-use/<uid>
``

• Validate the owner and permissions when the directory already exists.
• Do not inject or retain a partial mcp_servers.codex_app configuration if the native pipe fails.
• Surface the original socket permission error instead of presenting it as a config.toml transport error.
• Add a multi-user macOS regression test.

The local workaround works, but Codex Desktop should isolate its runtime sockets per operating-system user. 🚀

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.

Same issue, I had a different prior working build but experienced the same issue with the latest build. Thank you @dkovar-forge your workaround suggestion fixed it for me too! https://github.com/openai/codex/issues/40860#issuecomment-5432873833

Mine seems to be working now, I uninstalled chatgpt desktop, I restored my deleted .codex folder from previously uninstalling, and re-installed.

Hoping it doesn't break will update here if anything changes

I reproduced this on macOS in a multi-user setup and found a concrete underlying cause.

Environment:

• Codex Desktop: 26.820.60940
• bundled codex-cli: 0.150.0-alpha.8
• macOS, two simultaneously active local users

The app uses a machine-global directory:

/tmp/codex-browser-use

The first user to launch Codex creates it as that user's directory with mode 0755 (in my case luigi:wheel). When a second macOS user launches Codex, the app tries to create its own Unix socket under the same directory and fails with EACCES:

Failed to start the Codex app tools native pipe ... listen EACCES: permission denied /tmp/codex-browser-use/<uuid>.sock

The same EACCES occurs for the IAB/browser backend. Immediately afterwards, resuming a thread fails with:

failed to load configuration: invalid transport in mcp_servers.codex_app

So in this case the config.toml error is secondary/misleading; the actual failure is that the second user cannot create the native pipe/socket in the shared /tmp/codex-browser-use directory.

Workaround verified:

chmod 1777 /tmp/codex-browser-use

After that, the second user can open/resume threads normally.

Suggested fix: do not use a single machine-global directory for these sockets. On macOS, use the per-user $TMPDIR, or include the user UID in the directory name (for example /tmp/codex-browser-use-<uid>). That avoids cross-user permission collisions and is safer than making the shared directory world-writable.

This should be reproducible by:

1. Launch Codex as user A so /tmp/codex-browser-use is created as user A, mode 0755.
2. Switch to user B without logging out user A.
3. Launch Codex as user B and open/resume a thread.
4. Observe EACCES on /tmp/codex-browser-use/*.sock, followed by invalid transport in mcp_servers.codex_app.

I have had the same bug since yesterday and was not able to work for hours!
Thanks for the workaround!

I have a standard user account where I code because of risk of supply chain attacks, etc.
Codex macOS app on that account was not working BUT was working fine in the admin account.

I have confirmed that the chmod workaround worked for me.
/tmp/codex-browser-use was owned by the admin user with mode 0755.

Running in my admin account.

chmod 1777 /tmp/codex-browser-use

and then in the standard user account restarting ChatGPT fixed the invalid transport in mcp_servers.codex_app error.

New version fixed the issue and now I can access to the projects and conversations.