Telegram plugin dies mid-session: stdin pipe closed after MCP respawn

Bug

The Telegram MCP plugin (marketplace: telegram@claude-plugins-official) reliably dies mid-session when Claude Code respawns the plugin process. The new instance connects and starts polling, but the parent closes the stdin pipe within ~1 second, killing the MCP transport.

Reproduction

This happens consistently across sessions — not on every session, but frequently enough to be a daily occurrence. The pattern:

1. Plugin is running fine for hours
2. Claude Code respawns the plugin (possibly during context compaction or internal MCP reconnect)
3. New plugin instance starts, MCP connects, polling begins
4. stdin pipe closes ~1 second later
5. Plugin shuts down — no new instance is spawned to replace it
6. Plugin stays dead for the rest of the session

Diagnostic Log

From a stderr intercept added to server.ts (logged to ~/.local/state/miles-bot/telegram-plugin.log):

[2026-04-25T17:02:10.398Z] telegram plugin: file logging enabled
[2026-04-25T17:02:10.403Z] telegram channel: replacing stale poller pid=96441
[2026-04-25T17:02:10.403Z] telegram channel: SIGTERM received
[2026-04-25T17:02:10.403Z] telegram channel: shutting down (reason: signal/explicit)
[2026-04-25T17:02:10.408Z] telegram channel: MCP connected (pid=99541, ppid=99539)
[2026-04-25T17:02:10.549Z] telegram channel: bot.stop() resolved, exiting
[2026-04-25T17:02:10.872Z] telegram channel: polling as @miles_fam_ai_bot
[2026-04-25T17:02:11.484Z] telegram channel: stdin end event
[2026-04-25T17:02:11.484Z] telegram channel: shutting down (reason: signal/explicit)
[2026-04-25T17:02:11.486Z] telegram channel: stdin close event
[2026-04-25T17:02:13.487Z] telegram channel: force-exit timeout

Key observation: the old instance (pid 96441) and new instance (pid 99541) overlap — SIGTERM is sent to the old one, but the old one's bot.stop() resolves after the new one starts polling. The new instance's stdin closes 1 second after it connects.

This pattern repeats across multiple days:

[2026-04-25T10:00:05] — Same: replace stale -> new MCP -> stdin end at 10:01:51
[2026-04-24T10:00:03] — Same: replace stale -> new MCP -> stdin end at 10:01:14

The 10:00 AM instances are killed by a separate scheduled Claude session (a Desktop task that runs a gmail sweep) — that session's exit appears to kill the Telegram plugin in the main session too. The 17:02 instance today was mid-session with no external trigger.

Environment

• macOS 15.4 (Darwin 25.4.0)
• Claude Code CLI (latest as of 2026-04-25)
• Plugin: telegram@claude-plugins-official v0.0.6
• Runtime: Bun
• Transport: stdio

Expected Behavior

When Claude Code respawns a plugin, the new instance's stdin pipe should remain open for the lifetime of the session. If the respawn fails, Claude Code should retry or surface the failure to the user.

Workaround

Session restart (/exit + relaunch) reliably brings the plugin back. No in-session recovery is possible since the harness controls the stdio pipe.