Telegram MCP plugin (channels) repeatedly disconnects under load
Description
The Telegram channel plugin (plugin:telegram@claude-plugins-official) MCP stdio connection drops repeatedly during normal operation, especially when shell commands or sub-agents run. The bun process stays alive, but the stdio pipe between Claude Code and the plugin breaks.
Environment
- Claude Code: v2.1.202
- Telegram plugin: 0.0.6 (
claude-channel-telegram0.0.1) - OS: Debian Linux 6.1.0 (cloud VM, 8GB RAM)
- Launch:
claude --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions - Managed by systemd with a watchdog script
Steps to reproduce
- Start Claude Code in
--channelsmode with the Telegram plugin - Send messages that trigger tool calls (shell commands, file reads, sub-agents)
- Within 10-15 minutes, "Telegram MCP disconnected" appears in the session
- Disconnect repeats; reconnects are rare (observed 1 success out of 7 attempts)
- Eventually the bun process dies or loses its stdio pipe entirely
Observed data from a single 13-minute session
- 7 MCP disconnect events
- 1 successful auto-reconnect
- Every disconnect immediately follows tool completion ("Ran 2 shell commands")
- No memory pressure (6.2GB available out of 8GB, no swap, no OOM)
- bun process stays alive after disconnect (PID exists, file descriptors open)
- Eventually the stdio pipe breaks completely, bun's orphan watchdog fires
Crash frequency
5 full restart cycles in 2 hours (systemd Restart=always):
11:31 / 11:46 / 12:00 / 12:15 / 12:28
All same root cause: bun plugin reported dead after grace period.
Analysis
The plugin handles its side of the lifecycle correctly: orphan watchdog (polls ppid + stdin health every 5s), graceful shutdown on stdin EOF/close, PID file cleanup, stale-process replacement. The disconnect pattern suggests the issue is in Claude Code's MCP stdio transport layer. The connection drops when Claude is busy with tool execution and doesn't reliably reconnect afterward.
Workaround
Using --continue flag on restart to resume the previous session's conversation context. Preserves chat history but still requires a full restart cycle (~15-20s downtime).
Expected behavior
The MCP stdio connection should survive tool execution, or auto-reconnect reliably when the pipe drops temporarily.