Telegram plugin MCP server disconnects despite active polling

Description

The official Telegram plugin (claude-plugins-official/telegram/0.0.1) MCP server repeatedly disconnects during a session. The bot can send messages via tools, but inbound messages from Telegram never arrive because the plugin process gets killed/disconnected.

Steps to reproduce

1. Install the Telegram plugin and configure a bot token
2. Start a Claude Code session
3. Send messages to the bot on Telegram
4. Messages never arrive in the session
5. The MCP server shows as disconnected in the system reminders

Investigation findings

• The bot token and polling work correctly — getUpdates via curl returns messages
• Running the plugin manually (bun run start) works perfectly — it polls Telegram and emits notifications/claude/channel JSON-RPC notifications on stdout
• The MCP server connects initially (tools like reply work briefly) but then disconnects
• The plugin uses grammy's bot.start() long-polling simultaneously with MCP stdio transport — this seems to conflict with how Claude Code manages MCP server process lifecycles

Hypothesis

Claude Code's MCP client may have an idle timeout or heartbeat mechanism that kills the server process. The Telegram plugin is unique in that it runs a background long-poll loop (grammy) alongside the MCP stdio server. If the MCP layer is idle (no tool calls), the harness may assume the server is dead and terminate it — even though it's actively receiving Telegram messages in the background.

Environment

• Claude Code: v2.1.76 (Claude Desktop app)
• macOS Darwin 25.3.0
• Bun: 1.3.11
• Telegram plugin: 0.0.1
• Model: claude-opus-4-6

Workaround

Manually polling via curl .../getUpdates and sending via curl .../sendMessage works — the bot API is fully functional, only the MCP bridge is broken.