Bug: Codex startup blocks on MCP/App connector initialization, causing very slow launches #24397

What version of Codex CLI is running?

codex-cli 0.133.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5 xhigh

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty zsh

Codex doctor report

What issue are you seeing?

Codex startup becomes very slow when MCP servers, Apps/Connectors, or browser-related plugins are configured. It appears that
Codex eagerly initializes/checks MCP and connector state during session startup, even when those tools are not used in the
session.

This affects the basic launch experience. In my case, after removing/disabling the MCP/browser/apps startup path from my
default config, Codex startup became effectively instant, which strongly suggests the delay is caused by eager MCP/App
initialization.

I also saw startup errors like:

MCP client for codex_apps failed to start
MCP startup incomplete (failed: codex_apps)
token_invalidated
status: 401

A remote connector token being invalid should not slow down or pollute startup for a normal local coding session where that
connector is not used.

What steps can reproduce the bug?

1. Configure MCP/browser/app-related tools, for example:

[mcp_servers.chrome-devtools]
type = "stdio"
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]

[mcp_servers.node_repl]
command = "/Applications/Codex.app/Contents/Resources/node_repl"
startup_timeout_sec = 120

2. Enable Browser / Computer Use plugins and Apps/Connectors.
3. Start a normal Codex session that does not need browser automation or any external connector.
4. Observe that startup is slower and may show MCP/App connector initialization errors.
5. Remove the MCP servers and disable Apps/Browser/Computer Use from the default startup config.
6. Start Codex again. Startup becomes effectively instant.

Current workaround is to keep a fast default config and use a separate profile when browser/MCP tools are needed, for example:

codex --profile-v2 with-browser-mcp resume --last

But this is cumbersome because I must know in advance that MCP will be needed, restart/resume with a different profile, and
the already-started session cannot discover/connect to the MCP server on demand.

What is the expected behavior?

Codex should not block startup on MCP/App connector initialization unless that tool is required immediately.

Expected behavior:

1. Start the Codex session quickly.
2. Do not launch stdio MCP servers during startup unless explicitly configured as required/eager.
3. Do not validate remote App/Connector auth during startup unless the connector is actually used.
4. Make MCP/App capabilities discoverable without paying full startup/handshake cost.
5. Start and handshake with the MCP server only on first actual tool use.
6. If MCP startup/auth fails, surface the error at tool-use time, not every Codex launch.

This would avoid slow startup for normal coding sessions while still allowing browser/MCP tools to be used when needed.

Additional information

Environment:

Codex CLI/App version: 0.133.0-alpha.1
Platform: macOS arm64
Shell: zsh

This feels like a startup performance bug rather than a feature request, because configured but unused tools can make every
Codex launch slower and noisier.