Improve MCP startup timeout UX for corporate and VPN environments

Summary

When one or more MCP servers time out during startup, Codex currently emits a detailed warning for every server and then a second aggregate warning. The per-server warning also tells users to add or increase startup_timeout_sec.

This is especially noisy and misleading in corporate environments, where several MCP servers may depend on the same VPN, proxy, private DNS, or network route and therefore fail together.

Current behavior

For every timed-out server, the TUI shows a message similar to:

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

It then adds another summary:

⚠ MCP startup incomplete (failed: server-a, server-b, server-c)

Why increasing the timeout is a problematic default recommendation

Increasing startup_timeout_sec is useful only when the server is healthy and genuinely needs more time to initialize. It does not fix:

• a disconnected corporate VPN;
• an unavailable private route or proxy;
• DNS or firewall failures;
• expired authentication;
• an unhealthy MCP endpoint.

When multiple private MCP servers are affected by the same connectivity problem, increasing each timeout:

• makes every future Codex startup slower;
• multiplies the delay across several MCP servers;
• presents a shared network incident as several independent configuration problems;
• creates persistent config.toml drift that remains after connectivity is restored;
• hides the real diagnosis behind a workaround that cannot restore reachability.

There is also concrete user confusion around this recommendation: #29396 followed the suggested configuration for codex_apps and ended up with an invalid transport configuration. In #3408, a user similarly notes that changing the timeout only makes them wait longer before receiving the same failure.

Proposed UX

Show one compact warning after the startup round settles:

⚠ Some MCP servers could not start: server-a, server-b, server-c.
  Details: /mcp

Keep the detailed, per-server failure in /mcp, for example:

• server-a
  • Status: Startup failed
  • Last error: MCP server `server-a` did not finish starting within 30 seconds.
    Check the server and network connectivity before adjusting `startup_timeout_sec`.
  • Auth: OAuth
  • Tools: (none)

The last startup error can remain available for the session and be cleared after that server starts successfully.

Expected benefits

• Startup remains readable even when many corporate MCPs fail together.
• /mcp becomes the single place for actionable MCP status and diagnostics.
• Timeout configuration remains available for legitimately slow servers without being presented as the universal fix.
• Users are nudged toward checking shared connectivity first.

Related work

• #20167 covers the broader startup experience when an MCP appears stuck.
• #21318 proposes keeping optional MCP startup out of the first-turn critical path.
• #24439 proposes a dedicated MCP diagnostic command.

This request is narrower: improve the warning hierarchy and avoid recommending a longer timeout before the failure category is known.

Acceptance criteria

• Emit at most one aggregate startup warning for failed MCP servers.
• Include the failed server names and point users to /mcp.
• Preserve the detailed failure per server in /mcp.
• Clear a server's previous startup failure after a successful startup.
• For timeout failures, recommend checking server/network health before suggesting startup_timeout_sec.