Telegram plugin MCP server disconnects after ~3 messages in --channels mode

Description

The Telegram plugin (telegram@claude-plugins-official) consistently disconnects after handling roughly 3 message exchanges when running in --channels mode. Claude Code is closing the stdio pipe to the MCP server every 1-5 minutes, triggering the plugin's graceful shutdown.

The plugin itself is not crashing — it's being shut down by Claude Code recycling the MCP connection.

Environment

• Claude Code version: 2.1.119
• Plugin version: claude-channel-telegram 0.0.6
• Platform: Linux 6.8.0-106-generic
• Launch command: claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official

Evidence from debug.log

The plugin logs its full lifecycle to ~/.claude/channels/telegram/debug.log. Here's the repeating pattern — every instance lives 1-5 minutes before being killed:

[2026-04-25T13:33:16.332Z] -- server.ts boot pid=3647090 ppid=3647051 --
[2026-04-25T13:33:16.424Z] telegram channel: polling as @claudsky_bot
[2026-04-25T13:36:09.105Z] telegram channel: shutting down (cause=stdin-end)    ← 3 min

[2026-04-25T13:36:12.187Z] -- server.ts boot pid=3648669 ppid=3648664 --
[2026-04-25T13:36:12.348Z] telegram channel: polling as @claudsky_bot
[2026-04-25T13:37:05.188Z] telegram channel: shutting down (cause=stdin-end)    ← 53 sec

[2026-04-25T13:37:35.591Z] -- server.ts boot pid=3649277 ppid=3649271 --
[2026-04-25T13:37:35.705Z] telegram channel: polling as @claudsky_bot
[2026-04-25T13:38:44.195Z] telegram channel: shutting down (cause=stdin-end)    ← 1 min

Session duration summary (April 25)

| Duration | Cause |
|----------|-------|
| 2 min | stdin-end |
| 4 min | SIGTERM (replaced by new instance) |
| 3 min | stdin-end |
| 53 sec | stdin-end |
| 1 min | stdin-end |
| 1 min | SIGTERM |
| 44 sec | stdin-end |
| 2 min | stdin-end |

Average: ~2 minutes per session. At ~30-60s per Telegram round-trip, that's exactly ~3 commands before disconnect.

Shutdown causes

• ~70% stdin-end: Claude Code closes its end of the stdio pipe, the plugin's process.stdin emits 'end', triggering graceful shutdown. This is the MCP host recycling the connection.
• ~30% SIGTERM: A new plugin instance boots, finds the old PID still running via bot.pid, and sends SIGTERM (stale-poller replacement — working as designed, but shouldn't fire this often).

Race condition (secondary issue)

Occasionally two instances boot within the same millisecond and kill each other:

[13:26:54.601Z] boot pid=3635290 ppid=3635263
[13:26:54.609Z] replacing stale poller pid=3628607
[13:26:54.709Z] shutting down (cause=SIGTERM)        ← killed 108ms after boot
[13:26:54.693Z] boot pid=3635289 ppid=3635270        ← second instance kills first
[13:26:54.700Z] replacing stale poller pid=3635290

Expected behavior

In --channels mode, the MCP connection to the Telegram plugin should remain alive for the duration of the Claude session, not be recycled every 1-5 minutes. The Telegram plugin needs a persistent connection to maintain its polling loop and deliver inbound messages.

Plugin shutdown logic (for reference)

The plugin's shutdown is correct — it terminates when stdin closes to prevent zombie polling processes holding the Telegram bot token:

// server.ts:668-672
process.stdin.on('end', () => shutdown('stdin-end'))
process.stdin.on('close', () => shutdown('stdin-close'))
process.on('SIGTERM', () => shutdown('SIGTERM'))

The issue is on the Claude Code side — the MCP host shouldn't be closing the pipe this frequently in channel mode.