Telegram MCP plugin silently fails on long sessions — tool returns success but messages don't deliver

Summary

The Telegram MCP plugin (plugin:telegram:telegram) intermittently fails on long Claude Code sessions. The MCP reply tool returns a successful tool result, but the message never actually reaches the Telegram chat. /reload-plugins recovers it temporarily; the failure recurs within ~1–4 hours.

Symptoms

• MCP tool calls (mcp__plugin_telegram_telegram__reply) return sent (id: <n>) as if successful.
• Telegram chat receives nothing for those messages.
• Direct calls to the same Bot API token via curl deliver instantly (rules out token/bot/network issues).
• ToolSearch confirms the deferred MCP tools are "available" even when broken.
• 3 disconnects observed in a single session over ~12 hours on 2026-05-09.

Reproduction

1. Start a Claude Code session with the Telegram plugin and a verified bot token.
2. Use the MCP reply tool in a long-running session.
3. After ~1-4 hrs, MCP enters a degraded state where reply returns success but messages don't deliver.
4. /reload-plugins restores it briefly; the failure pattern recurs.

Expected

Reply tool either delivers or returns an explicit error.

Workaround

Full restart of Claude Code (Ctrl+D + claude) restores reliable delivery. /reload-plugins is unreliable.

Environment

• Claude Code (Opus 4.7 1M-context model, dynamic-mode loop)
• macOS Darwin 25.2.0 / arm64
• plugin:telegram:telegram
• Sessions where this hit: long-form (>1 hr), heavy tool use (Bash + WebFetch + multiple MCPs)

Related

Could be related to MCP transport buffering or stdin/stdout queue saturation. Also possibly tied to other MCP plugins disconnecting in the same session (Frame.io, Drive, etc. were unaffected, only Telegram disconnected silently).

🤖 Generated with Claude Code