[Bug] MCP connector startup starvation with large unauthenticated connector pools causes -32001 timeouts

Bug Description
Large claude.ai connector counts starve slower connectors at startup (-32001) Claude Code 2.1.220, Linux, claude.ai subscription auth, claudeai-proxy transport. With 28 claude.ai connectors (corporate org rollout; 17 of them never authenticated), the claude.ai Atlassian connector failed ~3 of 4 session starts with MCP error -32001: Request timed out — sometimes at connect, sometimes as a post-connect tools fetch failed. Ran broken for 1–2 weeks; worked fine in the claude.ai web app throughout. Denying 15 unused connectors (28 → 12) fixed it. Success went 1/4 → 4/4 on CLI runs plus 5/5 interactive restarts — 9 consecutive against a 75% failure baseline. Atlassian's connect time fell 3085ms → ~1010–1100ms. Nothing else changed. Ruled out by measurement: DNS, TLS/reachability (mcp.atlassian.com 401 in 118ms), routing, proxies, keyring, credentials, and client timeout (failures at 25–66s under a 180s MCP_TIMEOUT). Three suggestions: 1. Skip "needs authentication" connectors at startup until first use — they consumed startup capacity while never connecting, which is what caused this. 2. Surface the real error in /mcp. claude mcp list says tools fetch failed — MCP error -32001 outright; /mcp shows only a spinner. That gap sent the diagnosis into auth and then network dead ends. 3. Signal that MCP settings changes need a restart. deniedMcpServers applies only to new sessions, so running sessions keep failing after the correct fix — it reads as "the fix didn't work" and invites reverting it. claude --fork-session was needed on each session.

Environment Info

• Platform: linux
• Terminal: konsole
• Version: 2.1.220
• Feedback ID: 22a6b4f0-e62c-4edd-b821-17a7ec3688ef

Errors

[]