-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Closed
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIbugSomething isn't workingSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers
Description
Symptoms
- TUI appears to hang during startup when MCP servers are configured
- No "Booting MCP server: {name}" progress messages displayed
- Startup delay equals cumulative MCP server initialization time (~10-20 seconds at my case)
- User sees blank screen with no feedback
Root Cause
The blocking call to notify_sandbox_state_change() in Session::new() (lines 651-660 in codex.rs)
waits for ALL MCP servers to fully initialize before returning. This prevents the TUI event loop
from starting, so McpStartupUpdateEvent messages are emitted but never consumed or displayed.
Impact
- Poor user experience - app appears frozen during startup
- No visibility into MCP initialization progress
Introduced In
Commit c6f68c9df (PR #7112) - "feat: declare server capability in shell-tool-mcp"
Fix
Move sandbox state notification into each MCP server's background init task, sending the
notification immediately after the server becomes Ready. This allows Session::new() to return
immediately while still ensuring servers receive sandbox state before handling tool calls.
ateodorowicz
Metadata
Metadata
Assignees
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIbugSomething isn't workingSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers