MCP startup should not block tool listing or thread startup

Summary

A configured MCP server that is still starting or unreachable can block core Codex workflows when the session builds the aggregated MCP tool list. This makes optional MCP extensions behave like startup-critical dependencies.

Root cause found locally

codex-mcp currently waits on pending MCP clients from McpConnectionManager::list_all_tools() through AsyncManagedClient::listed_tools(). When an MCP server is unreachable and has no startup tool cache, the first turn/tool-router construction can wait until MCP startup timeout instead of keeping chat usable.

Proposed fix

I have a local/fork branch that changes listed_tools() to skip clients that are still initializing and have no cached startup tools. Cached startup tools are still returned while initialization continues; once startup completes, tools are listed normally.

Branch:
https://github.com/caokaizz/codex/tree/codex/mcp-nonblocking-tool-list

Compare:
https://github.com/openai/codex/compare/main...caokaizz:codex:codex/mcp-nonblocking-tool-list

Commit:
9502ad125c Avoid blocking tool listing on MCP startup

Validation run locally

• just test -p codex-mcp list_all_tools_skips_pending_client_without_cached_tool_info_snapshot
• just test -p codex-mcp (88 passed)
• just fmt
• just fix -p codex-mcp

Note

I attempted to open a PR from the fork branch, but GitHub returned: caokaizz does not have the correct permissions to execute CreatePullRequest.