Feature: Lazy MCP server initialization (don't block startup)

Resolved 💬 3 comments Opened Feb 18, 2026 by alangmartini Closed Feb 22, 2026

Problem

Claude Code blocks the input prompt until all configured MCP servers have spawned and completed their tool discovery handshake. With even 1-2 MCP servers configured, this adds 3-10+ seconds to every session start.

This is frustrating because the user can't type anything during this time, even though MCP tools are rarely needed in the very first prompt.

Proposed solution

Initialize MCP servers lazily or in parallel with user input:

  1. Show the input prompt immediately
  2. Spawn MCP servers in the background while the user types
  3. If the first prompt doesn't need any MCP tools, there's zero perceived delay
  4. If it does, wait only at tool invocation time (with a brief "connecting to MCP server..." indicator)

This is similar to how ENABLE_TOOL_SEARCH already defers tool definitions from context — but applied to the actual process startup.

Current workarounds

  • Remove all MCP servers from config (defeats the purpose)
  • Use --strict-mcp-config with an empty file (inconvenient)
  • Set MCP_TIMEOUT to cap wait time (still blocks)

Expected behavior

MCP server readiness should never block the user from typing their first prompt. The startup sequence should be:

1. Load config          → instant
2. Show input prompt    → instant  
3. Spawn MCP servers    → background (parallel with user typing)
4. User submits prompt  → if MCP tools needed, wait for ready; otherwise proceed immediately

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗