Telegram plugin: MCP stdio server dies on conversation branch/recycle, losing messages

Summary

The Telegram channel plugin (telegram@claude-plugins-official v0.0.1) uses a stdio-based MCP server that gets killed whenever Claude Code recycles the MCP connection — on conversation branch, context compression, or internal timeouts. This makes the bot silently stop polling Telegram, dropping all inbound messages until the user manually runs /mcp to reconnect.

Repro

1. Install the Telegram plugin, pair a chat
2. Send a message from Telegram → works, bot replies
3. Run /branch (or wait for context compression / MCP recycle)
4. Send another message from Telegram → silence. Bot process is dead.
5. Run /mcp → reconnects, but messages sent during downtime are lost

Root cause

The server (server.ts) runs grammy's bot.start() long-polling alongside the MCP stdio transport in a single process. When Claude Code closes the stdio pipe, the process exits and Telegram polling stops. There's no mechanism to:

• Auto-reconnect the MCP server after a disconnect
• Keep the bot process alive independently of the stdio lifecycle
• Queue/replay messages that arrived while disconnected

Expected behavior

A channel plugin should maintain a persistent connection to the external service regardless of Claude Code's internal MCP lifecycle. Messages arriving while the MCP pipe is down should be queued and delivered on reconnect.

Suggested fix

Either:

1. Framework-level: Auto-reconnect stdio MCP servers when they die, or add a keepalive mechanism
2. Plugin-level: Switch to HTTP/SSE transport so the bot runs as a persistent daemon decoupled from Claude Code's stdio pipe
3. Hybrid: Run the bot poller as a separate background process that writes to a message queue; the MCP server reads from the queue on (re)connect

Environment

• macOS Darwin 25.3.0
• Claude Code (latest as of 2026-03-20)
• Plugin: telegram@claude-plugins-official v0.0.1
• Runtime: bun