Invalid transport error when setting `mcp_servers.codex_apps.startup_timeout_sec`

I also encountered a similar error. I am using Codex within the Microsoft Ubuntu WSL environment; this issue began appearing after I updated from version 0.137 to 0.142.

我也遇到这个问题了,还以为是我电脑的自身问题呢,看到你们的问题,这下我总算放心了

Still reproducible on codex-cli 0.144.1 with Linux x86_64, ChatGPT Pro/Max auth, and tmux 3.4.

I reproduced the full sequence today:

1. Launch Codex with apps enabled and a populated ~/.codex/cache/codex_apps_tools cache.
2. gpt-5.6-sol responds successfully, but codex_apps remains in Booting MCP server state.
3. At 30 seconds the TUI prints the timeout and recommends:

[mcp_servers.codex_apps]
startup_timeout_sec = 60

1. Adding that exact table makes Codex fail before startup with:

Error loading config.toml: invalid transport in `mcp_servers.codex_apps`

The current source constructs this host-owned server with a fixed 30-second timeout:
https://github.com/openai/codex/blob/main/codex-rs/codex-mcp/src/mcp/mod.rs#L539-L553

This appears to be the generic MCP timeout remediation being shown for a host-owned server whose user configuration cannot be expressed as a transport-less mcp_servers entry. A fix could either expose a valid dedicated timeout setting, merge a user timeout override into the synthesized server, or suppress the unusable suggestion for codex_apps.

codex doctor --json returned no output on this build.

I have exactly the same issue as @EazyReal

Confirmed on codex-cli 0.144.4, native Ubuntu 26.04 x86_64.

The TUI warning still recommends configuring the implicit server:

Add or adjust startup_timeout_sec in your config.toml:
[mcp_servers.codex_apps]
startup_timeout_sec = XX

However, the suggested override is not representable because codex_apps has no user-configurable transport:

$ codex mcp list
No MCP servers configured yet.

$ codex mcp get codex_apps
Error: No MCP server named 'codex_apps' found.

$ codex -c mcp_servers.codex_apps.startup_timeout_sec=90 --no-alt-screen
Error loading config.toml: invalid transport
in `mcp_servers.codex_apps`

A full Codex/app-server restart does not change this deterministic config failure.

Expected behavior: for a host-owned implicit MCP, either expose a dedicated supported timeout setting or suppress the generic user-MCP suggestion. Ideally the warning should also preserve the actual upstream Apps/Connectors error instead of only reporting a tools/list timeout.

Can we just say +1 instead of AI dumping itself here?

+1 — still reproducible on codex-cli 0.146.0 (native Linux x86_64, ChatGPT auth).

+1 — still reproducible on codex-cli 0.149.1 (native Linux x86_64, ChatGPT auth).

+1 — having the same on codex app running on debian 13 wsl env
has anyone found a temp fix for this yet?

Same issue after today update (also i can not open any of previous chats)

Claude fixed it:

Today at 13:12, the CLI was updated (to 0.150.0-alpha.8), and at 13:31, the application itself was updated. The new CLI requires that each MCP server have a valid transport, i.e., a specified command (or URL). And when the thread starts, the application adds the mcp_servers.codex_app section on top of the config, in which, in WSL mode, only enabled remains — without the command. The CLI rejects the entire config, and each thread/start and thread/resume fails with invalid transport. This is clearly visible in the application log, and there’s also an accompanying symptom of version mismatch: ignoring invalid experimental feature enablement keys: apps_mcp_path_override. I reproduced this exactly: the {"enabled"=false} override without a command results in invalid transport, but with a command — it doesn’t. What I did Added a transport stub to the end of config.toml: [mcp_servers.codex_app] command = "" enabled = false The app’s override doesn’t replace the section; it merges with it, so the missing command is now always present, and the config loads. The form is exactly the one the app itself uses for the disabled codex_app, so nothing extra is launched; if the app sends a complete working configuration, it will override the stub, and the app’s tools will start working.

Thanks! Though that disables it right? But at least you got it running.

Insane with all the AI commits they aren't even testing it.