Disabled remote HTTP MCP servers still trigger auth probing and add ~15s startup latency

Disabled Remote MCP Startup Latency Issue

Summary

Codex CLI startup is slow by about 10 to 15 seconds when ~/.codex/config.toml contains certain remote MCP server entries, even when those entries are configured with enabled = false.

The slowdown appears to happen during MCP auth or inventory initialization rather than normal CLI startup:

• codex --help and codex --version complete in about 0.02s
• interactive or session startup shows about 15s delay
• codex mcp list also takes about 15.1s
• a fresh CODEX_HOME with no MCP config makes codex mcp list complete in about 0.02s

From the local Codex log, the startup bottleneck appears to be:

• session_init.auth_mcp ... time.idle=15.0s

The issue seems specifically related to disabled remote streamable HTTP MCP definitions still being probed for auth status.

Environment

• Codex CLI: 0.118.0
• Platform: Linux x86_64
• Shell: bash

Fast Baseline

Minimal config:

approval_policy = "never"
sandbox_mode = "danger-full-access"

Command:

CODEX_HOME=/tmp/codex-test /usr/bin/time -f 'real=%e' codex mcp list

Result:

real=0.02
No MCP servers configured yet. Try `codex mcp add my-tool -- my-command`.

Minimal Reproduction

Single disabled remote MCP server:

approval_policy = "never"
sandbox_mode = "danger-full-access"

[mcp_servers.disabled_remote_browser]
url = "http://redacted-remote-browser.invalid/mcp"
enabled = false
startup_timeout_sec = 3.0

Command:

CODEX_HOME=/tmp/codex-test /usr/bin/time -f 'real=%e' codex mcp list

Result:

real=15.08
Name                     Url                                         Bearer Token Env Var  Status    Auth
disabled_remote_browser  http://redacted-remote-browser.invalid/mcp  -                     disabled  Unsupported

Additional Reproductions

The same ~15s delay was reproduced with these disabled entries:

[mcp_servers.disabled_remote_browser_2]
url = "http://redacted-remote-browser-2.invalid/mcp"
enabled = false
startup_timeout_sec = 3.0

[mcp_servers.disabled_remote_windows]
url = "http://redacted-remote-windows.invalid/mcp"
enabled = false
startup_timeout_sec = 8.0

[mcp_servers.disabled_remote_windows_2]
url = "http://redacted-remote-windows-2.invalid/mcp"
enabled = false
startup_timeout_sec = 3.0

Each of those alone made codex mcp list take about 15.06s to 15.08s.

Smaller delays were also observed for disabled OAuth-capable remote MCP servers:

• context7 about 2.45s
• huggingface about 1.40s

By contrast, these were fast in isolation:

• disabled bearer-token remote MCP server: about 0.02s
• another disabled bearer-token remote MCP server: about 0.02s
• enabled github bearer-token server: about 0.02s
• enabled unsupported remote MCP server: about 0.05s

On the full real-world config, removing the four disabled remote browser or windows MCP entries above reduced codex mcp list from about 15.15s to about 1.56s.

Expected Behavior

Disabled MCP servers should not materially slow down startup or /mcp inventory loading.

At minimum, one of these should be true:

1. enabled = false skips auth probing or remote status discovery entirely.
2. Disabled servers are shown from static config only, without network calls.
3. Auth probing for disabled remote MCP servers uses a short timeout instead of a fixed ~15s wait.

Also, if startup_timeout_sec is intended to control this path, it does not appear to be applied here.

Related Evidence

The public source that looks relevant is in the MCP auth status computation path, especially:

• codex-rs/codex-mcp/src/mcp/auth.rs
• compute_auth_statuses(...)
• determine_streamable_http_auth_status(...)

This may be related to broader reports about slow MCP inventory loading, but this reproduction isolates a more specific case: disabled remote HTTP MCP entries still causing startup-scale latency.