{"version":"2.1.274","anchor":"stdio-mcp-servers-that-exit-mid-initialize-after-a-probe-tim","canonical_anchor":"stdio-mcp-servers-that-exit-mid-initialize-after-a-probe-tim","heading":"Stdio MCP servers that exit mid-initialize after a probe timeout now get one restart","tier":"notice","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274\/e\/stdio-mcp-servers-that-exit-mid-initialize-after-a-probe-tim","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274","markdown":"### Stdio MCP servers that exit mid-initialize after a probe timeout now get one restart\n\nStdio MCP servers that exit right after a startup probe times out now get one automatic restart\n\n**What**\n\nWhen Claude Code connects to an MCP server over stdio (standard input\/output, used for local server processes), it sometimes runs a version-negotiation probe first. If that probe times out and the server process then closes while still initializing, Claude Code now recognizes this specific pattern - a likely slow-starting server that exits on requests sent before it's ready - and restarts the server once without the probe, using whatever time is left in the connection budget.\n\nPreviously, only a different failure (a version-negotiation error causing the connection to close) triggered a stdio server restart; a probe-timeout-induced close was not handled.\n\n**Why**\n\nThis reduces false failures for MCP servers that are simply slow to start up, giving them a second chance to connect properly instead of failing outright.\n\n- Area: MCP\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}