MCP plugin stdio transport: auto-reconnect on pipe break

Resolved 💬 3 comments Opened Mar 23, 2026 by py77 Closed Mar 26, 2026

Problem

MCP plugins using stdio transport (e.g., the official Telegram channel plugin) lose their connection permanently when the child process crashes or the pipe breaks. The only recovery is restarting the entire Claude Code session manually.

This is especially problematic for channel plugins (Telegram, Slack, etc.) where the user may be away from the terminal and relying on the channel as their primary interface. If the MCP pipe drops while the user is remote, they lose all channel connectivity with no way to restore it until they're physically back at the machine.

Current behavior

  1. Claude Code spawns the plugin via bun run ... start over stdio
  2. If the Bun process crashes (unhandled rejection, OOM, network hiccup in Telegram long-polling, etc.), the stdio pipe breaks
  3. The MCP connection shows as disconnected
  4. No automatic reconnect attempt is made
  5. User must restart Claude Code or manually reconnect via /mcp

Expected behavior

  • Claude Code detects when an MCP plugin's stdio pipe breaks
  • Automatically attempts reconnection with exponential backoff (e.g., 1s → 2s → 4s → ... → 60s cap)
  • Logs reconnection attempts to stderr so the user can see what happened
  • Optionally: expose a heartbeat/health-check mechanism for MCP servers so broken connections are detected faster (not just on next tool call)

Environment

  • OS: Windows 11 Pro
  • Bun: v1.3.11 (latest)
  • Plugin: telegram@claude-plugins-official v0.0.1
  • Transport: stdio (StdioServerTransport from @modelcontextprotocol/sdk)

Additional context

The Telegram plugin uses Grammy's bot.start() long-polling. Any transient Telegram API error or Bun runtime issue on Windows can kill the process. The plugin itself handles errors gracefully (corrupted JSON recovery, photo download failures logged but non-fatal), but a process-level crash is unrecoverable from the MCP transport side.

For channel plugins specifically, connection reliability is critical since they serve as the user's remote access path to the assistant.

View original on GitHub ↗

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