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

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

26.820.60940

What subscription do you have?

ChatGPT Team

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The Codex desktop app cannot resume an existing thread because it reports an invalid MCP server configuration.

The app shows the following error:

"ChatGPT cannot load config.toml, so this thread cannot be resumed.
Fix config.toml: invalid transport in mcp_servers.codex_app.
After saving the file, reopen the thread."

I checked my local Codex configuration and there is only one config.toml file:

~/.codex/config.toml

The issue persists even after checking/removing the relevant MCP configuration and restarting the app.

It appears that the app may still be loading or generating an mcp_servers.codex_app configuration that is not present in the user config.toml.

What steps can reproduce the bug?

Open the Codex desktop app on macOS.
Open an existing thread.
The app attempts to resume the thread.
An error appears saying that config.toml cannot be loaded because of an "invalid transport in mcp_servers.codex_app".
Check the local configuration files with:

find ~ -name "config.toml" -print 2>/dev/null | grep -Ei "codex|chatgpt"

Only one configuration file is found:

~/.codex/config.toml

Check/remove the MCP configuration related to codex_app from config.toml and restart the Codex app.
Reopen the affected thread.

Expected result:
The thread should open normally.

Actual result:
The same "invalid transport in mcp_servers.codex_app" error appears and the thread cannot be resumed.

What is the expected behavior?

The Codex app should load the existing thread normally.

If mcp_servers.codex_app is an internal or app-managed MCP server, its configuration should not cause the user's config.toml to be considered invalid.

The app should not prevent an existing thread from being resumed because of an MCP configuration that is not present in the user's config.toml.

Additional information

Codex App version: 26.820.60940
Platform: Darwin 25.5.0 arm64 arm

I searched for other Codex/ChatGPT config.toml files with:

find ~ -name "config.toml" -print 2>/dev/null | grep -Ei "codex|chatgpt"

The only file found was:

~/.codex/config.toml

The error specifically references:

mcp_servers.codex_app

However, after checking/removing the relevant MCP configuration from my local config.toml and restarting the app, the issue still occurs.

This makes me suspect that codex_app may be an app-managed/internal MCP configuration rather than something coming from my user configuration.

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

Desktop app 26.820.7780.0: resuming WSL-hosted threads fails with "invalid transport in mcp_servers.codex_app" #40819
[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
[Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works #40715
Codex Windows App fails in WSL with "invalid transport in mcp_servers.codex_app" #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.

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.

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

Version 26.820.60940

Windows (WSL mode)

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

see: #40881 (comment)

🎉 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.

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
I confirmed that no available config.toml contained:
```
[mcp_servers.codex_app]
```
I verified that the bundled plugin manifest contained a valid STDIO transport with command, args, and cwd.
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.

I searched the desktop logs for:

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

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.

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

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

I inspected the packaged application code in app.asar and found that the Unix path is hardcoded as:
```
/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.
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

Log into macOS user A and start Codex.
Codex creates /tmp/codex-browser-use, owned by user A with mode 0755.
Leave the directory in place.
Log into macOS user B and start Codex.
User B cannot bind a socket inside the directory.
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:

#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:

$TMPDIR/codex-browser-use

or:

/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.

@dkovar-forge

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! #40860 (comment)

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:

Launch Codex as user A so /tmp/codex-browser-use is created as user A, mode 0755.
Switch to user B without logging out user A.
Launch Codex as user B and open/resume a thread.
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.

Navigation Menu

Repository navigation

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

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

Environment

Exact failure

Key isolation result

Ruled out on the failing macOS user

Additional observation

Why this case may be useful

Root cause

What fixed it

How I investigated it

Reproduction scenario

Notes for Windows and WSL users

Suggested upstream fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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

github-actions commented on Aug 26, 2026

daineball commented on Aug 26, 2026

andyrees commented on Aug 26, 2026

subinznz commented on Aug 26, 2026

NodeA-mats commented on Aug 26, 2026

NoobMaster233 commented on Aug 26, 2026

parrow-d commented on Aug 26, 2026

mo-mew commented on Aug 26, 2026

taobaibais commented on Aug 26, 2026

taobaibais commented on Aug 26, 2026

hileo1421 commented on Aug 26, 2026

Environment

Exact failure

Key isolation result

Ruled out on the failing macOS user

Additional observation

Why this case may be useful

taobaibais commented on Aug 26, 2026

sabeti commented on Aug 26, 2026

LuisRibeiro2903 commented on Aug 26, 2026

data-amateur commented on Aug 26, 2026

arthurbarret0 commented on Aug 26, 2026

dkovar-forge commented on Aug 27, 2026

Root cause

What fixed it

How I investigated it

Reproduction scenario

Notes for Windows and WSL users

Suggested upstream fix

sdp0825 commented on Aug 27, 2026

HTDuck commented on Aug 27, 2026

parrow-d commented on Aug 27, 2026

kalaktatla commented on Aug 27, 2026

NorthernMoodler commented on Aug 27, 2026

lisgaca-des commented on Aug 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions