Telegram MCP plugin (channels) repeatedly disconnects under load

Open 💬 0 comments Opened Jul 7, 2026 by danieloz147

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-telegram 0.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

  1. Start Claude Code in --channels mode with the Telegram plugin
  2. Send messages that trigger tool calls (shell commands, file reads, sub-agents)
  3. Within 10-15 minutes, "Telegram MCP disconnected" appears in the session
  4. Disconnect repeats; reconnects are rare (observed 1 success out of 7 attempts)
  5. 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.

View original on GitHub ↗