Skip to content

Invalid transport error when setting mcp_servers.codex_apps.startup_timeout_sec #29396

Open
Open
Invalid transport error when setting mcp_servers.codex_apps.startup_timeout_sec#29396
Labels
CLIIssues related to the Codex CLIbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updatesmcpIssues related to the use of model context protocol (MCP) servers

Description

@siddhpant
siddhpant
opened on Jun 22, 2026

When starting Codex (v0.141.0), I got the following error:

⚠ MCP client for `codex_apps` timed out after 30 seconds. Add or adjust `startup_timeout_sec` in your config.toml:
  [mcp_servers.codex_apps]
  startup_timeout_sec = XX

⚠ MCP startup incomplete (failed: codex_apps)

So I did that and added the following in config.toml:

[mcp_servers.codex_apps]
startup_timeout_sec = 60

After that codex fails to start:

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    mcpIssues related to the use of model context protocol (MCP) servers
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 22, 2026

  2. noneNote commented on Jun 29, 2026

    @noneNote
    noneNote
    on Jun 29, 2026

    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.

  3. xiaoying706 commented on Jun 30, 2026

    @xiaoying706
    xiaoying706
    on Jun 30, 2026

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

  4. EazyReal commented on Jul 10, 2026

    @EazyReal
    EazyReal
    on Jul 10, 2026

    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.

  5. skorotkiewicz commented on Jul 10, 2026

    @skorotkiewicz
    skorotkiewicz
    on Jul 10, 2026

    I have exactly the same issue as @EazyReal

  6. qixuancao commented on Jul 15, 2026

    @qixuancao
    qixuancao
    on Jul 15, 2026

    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.

  7. siddhpant commented on Jul 15, 2026

    @siddhpant
    siddhpant
    on Jul 15, 2026
    Author

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

  8. StackOverFlow11 commented on Jul 29, 2026

    @StackOverFlow11
    StackOverFlow11
    on Jul 29, 2026

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

  9. vini-cius commented on Aug 26, 2026

    @vini-cius
    vini-cius
    on Aug 26, 2026

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

  10. ThunderRonin commented on Aug 26, 2026

    @ThunderRonin
    ThunderRonin
    on Aug 26, 2026

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

  11. KonstantinPopadyuk commented on Aug 26, 2026

    @KonstantinPopadyuk
    KonstantinPopadyuk
    on Aug 26, 2026

    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.

  12. siddhpant commented on Aug 26, 2026

    @siddhpant
    siddhpant
    on Aug 26, 2026
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updatesmcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions