MCP stdio transport to plugin silently dies, no disconnect/error logged

Summary

MCP stdio transport to plugin:telegram@claude-plugins-official (v0.0.6) silently breaks multiple times per day. The plugin's bun process stays alive, but Claude Code loses the stdio pipe. No disconnect, error, or close event is logged — tools just disappear from the available set.

Environment

• Claude Code: 2.1.112 (npm, macOS)
• macOS on M4 Max
• Plugin: plugin:telegram@claude-plugins-official v0.0.6 (grammy-based Telegram bot, stdio transport)
• Session launched with --debug --channels "plugin:telegram@claude-plugins-official" inside tmux

Reproduction

Happens spontaneously after 1-8 hours of normal operation. Observed 8+ occurrences over 3 days with --debug enabled.

Debug log evidence

Session debug log: f1c60f67-9769-4f2c-bf5f-aabaae9a1754.txt (7.4 MB, 3 days of data).

Typical failure sequence (2026-04-20)

Last successful tool call:

11:06:07.959Z [DEBUG] MCP server "plugin:telegram:telegram": Tool 'reply' completed successfully in 176ms

7 minutes later — tool gone, no intermediate events:

11:13:20.683Z [ERROR] Error: Tool mcp__plugin_telegram_telegram__reply not found
11:13:20.684Z [ERROR] Error: Tool mcp__plugin_telegram_telegram__reply not found
(8 identical errors in 25ms)

Between 11:06 and 11:13 — zero telegram-related log entries. No disconnect, no transport close, no error, no EOF. The stdio pipe just silently stopped working.

All observed failures (same session)

| Timestamp | Last success before | Gap | Auto-reconnect? |
|-----------|-------------------|-----|-----------------|
| Apr 17 23:29 | ~23:24 | ~5 min | No |
| Apr 18 07:51 | ~07:47 | ~4 min | No |
| Apr 18 14:05 | ~14:00 | ~5 min | No |
| Apr 18 23:18 | ~23:15 | ~3 min | No |
| Apr 19 09:03 | ~09:00 | ~3 min | No |
| Apr 19 23:06 | ~23:03 | ~3 min | No |
| Apr 20 05:55 | ~05:50 | ~5 min | Yes (auto) |
| Apr 20 11:13 | 11:06 | 7 min | No (manual /mcp) |

Auto-reconnect (rare, only once observed)

05:55:44.960Z [DEBUG] MCP server "plugin:telegram:telegram": Starting connection with timeout of 30000ms
05:55:45.134Z [DEBUG] MCP server "plugin:telegram:telegram": Successfully connected (transport: stdio) in 180ms
05:55:47.153Z [DEBUG] MCP server "plugin:telegram:telegram": UNKNOWN connection closed after 2s (cleanly)
05:55:47.153Z [DEBUG] MCP server "plugin:telegram:telegram": Cleared connection cache for reconnection
05:55:47.156Z [DEBUG] MCP server "plugin:telegram:telegram": Starting connection with timeout of 30000ms
05:55:47.309Z [DEBUG] MCP server "plugin:telegram:telegram": Successfully connected (transport: stdio) in 153ms

This is the only time the disconnect was detected and auto-reconnected. In all other 7 cases, the connection silently died with no detection.

What doesn't cause it

• Plugin autoupdate was initially suspected (and did cause one failure on Apr 17 at 10:58 — see below). We disabled it via "autoUpdate": false in known_marketplaces.json. Failures continued with identical pattern.
• grammy/Telegram polling issues: the bun process stays alive (verified via ps, lsof), bot.pid is valid. The plugin's internal retry loop and orphan watchdog are fine.
• macOS sleep: failures happen throughout the day (09:00, 11:13, 14:05, 23:18), not correlated with sleep/wake cycles.

Separate issue: Plugin autoupdate kills MCP connections

On Apr 17, the periodic Plugin autoupdate: checking installed plugins check caused the first observed failure:

10:58:22.537Z [DEBUG] Plugin autoupdate: checking installed plugins
10:58:22.547Z [DEBUG] Using manifest version for telegram@claude-plugins-official: 0.0.6

2 minutes later, tools dropped from 6/214 to 5/210 deferred. This was fixed by adding "autoUpdate": false to known_marketplaces.json, but the silent transport death continued independently.

Expected behavior

1. When the MCP stdio transport breaks, a [DEBUG] MCP server "...": connection closed or [ERROR] event should be logged
2. Claude Code should detect the broken pipe and auto-reconnect (like it does for claude.ai ClickUp SSE transport — observed working correctly in the same session)
3. The plugin autoupdate check should not disconnect running MCP servers

Workaround

Manual /mcp → select plugin → Reconnect. Works every time but requires user intervention.