Grok 1.0.13 closes connected MCP servers when a sibling fails during batch startup

[antst]

Version

grok 1.0.13 (5e9a58528b76) [stable] on Linux.

Summary

When one or more MCP servers fail during Grok's startup batch, Grok tears down MCP servers that already initialized successfully. In the reproductions below, agent_sessions connected and advertised six tools, sibling initialization then failed, and Grok closed agent_sessions' stdio. Its connector process exited and its live presence disappeared while the Grok TUI remained healthy.

Grok documents that it scans Claude MCP configuration from ~/.claude.json by default: https://docs.x.ai/build/features/mcp-servers

The affected sibling entries were imported from that Claude configuration. The exact transports resolved by Grok in these incidents were stdio wrappers to remote services:

• context7: npx -y @upstash/context7-mcp@latest
• tavily: npx -y tavily-mcp@latest
• git: uvx mcp-server-git

The same Context7 and Tavily tool sets were active from Claude Code on the same host. This is a control observation only; I am not asserting why their Grok-side handshakes failed.

Reproduction

1. Configure a known-good stdio MCP server plus the sibling servers above in Claude-format configuration.
2. Start Grok with its default Claude-config discovery.
3. Observe the known-good server connect before one or more siblings fail initialization.
4. Observe that the known-good server's stdio is closed and its process exits, even though the Grok TUI remains running normally.

Evidence

Reproduction 1 (2026-09-04T00:19:22Z):

00:19:22.144 agent_sessions mcp_server_connected transport=stdio tool_count=6
00:19:22.145 git            mcp_server_failed error_type=client_error
             error_message="MCP service error: Transport closed"
00:19:22.145 tavily         mcp_server_failed error_type=handshake_failed
             error_message="connection closed: initialize response"
00:19:22.145 context7       mcp_server_failed error_type=handshake_failed
             error_message="connection closed: initialize response"
00:19:22.145 mcp_init_completed succeeded=3 failed=3

Afterward, the Grok TUI was still at its normal prompt, but the agent_sessions connector process was gone and its presence never appeared during a 75-second observation window.

Reproduction 2 (2026-09-04T01:09:48Z):

01:09:48.062 agent_sessions mcp_server_connected transport=stdio tool_count=6
01:09:48.062 git            mcp_server_connected transport=stdio tool_count=12
01:09:48.062 context7       mcp_server_failed error_type=handshake_failed
             error_message="connection closed: initialize response"
01:09:48.062 tavily         mcp_server_failed error_type=handshake_failed
             error_message="connection closed: initialize response"
01:09:48.062 mcp_init_completed succeeded=4 failed=2

Again, the TUI remained healthy, but agent_sessions had received EOF, its connector exited, and its presence was absent.

Across a controlled six-launch sample, the five launches with no sibling MCP failures retained exactly one agent_sessions connector and published presence. The one launch with Context7 and Tavily initialization failures retained no connector and published no presence. Separate launches with zero sibling failures also retained the connector consistently.

Expected behavior

A sibling MCP initialization failure should be isolated to that server. Servers that have already initialized successfully should remain connected and usable for the lifetime of the Grok session.

Observed behavior

A sibling failure during batch startup closes the whole MCP batch, including servers that had already connected successfully. This makes one flaky or incompatible sibling disable unrelated MCP integrations.

Suggested direction

Please isolate startup failures per MCP server and preserve successful sessions rather than closing every server in the batch.