stdio MCP server killed every ~5 min when JSON-RPC ping response misses timeout window

Summary

Stdio MCP servers (reproed with the official Telegram plugin v0.0.6) are killed by Claude Code at ~5-minute intervals when the server fails to respond to a JSON-RPC ping request within an apparent timeout window. The kill manifests as a SIGTERM to the server process, paired with the visual "Telegram MCP server failed" red text and "1 claude.ai connector needs auth" yellow text in the status bar. Inbound channel notifications drop until the user manually runs /mcp.

This bug appears to be the upstream cause of several existing issues: #50607, #53617, #43049, #45985, #46334.

Environment

• macOS 24.5.0 (Darwin)
• Claude Code 2.1.121 and 2.1.122 (both reproduced)
• Telegram plugin v0.0.6 (anthropics/claude-plugins-official)
• --channels flag enabled
• Stdio transport (bun-run wrapper → server.ts)

Reproduction

1. Start claude --channels and verify Telegram MCP connects successfully.
2. Pipe the bot's stderr to a log file (e.g., wrap the plugin start script to tee stderr) so you can observe MCP traffic.
3. Add a small bot.on('message:text', ...) log line that records timestamp + process.uptime() to confirm bot lifetime, and a process.stdin.on('data', chunk => ...) log line to capture small stdin packets.
4. Wait without interacting. At approximately 5 minutes from spawn, observe one of two outcomes:

• Outcome A (kill): bot receives SIGTERM at uptime ~300s, exits cleanly. A new bot is spawned by CC. Inbound notifications stop until /mcp.
• Outcome B (survive): bot receives a JSON-RPC ping (41 bytes: {"method":"ping","jsonrpc":"2.0","id":N}\n), responds via the MCP SDK's built-in ping handler, and continues running. Subsequent pings arrive at ~5-min intervals.

The outcome appears to depend on whether the bot's response reaches CC within some timeout. Bots actively handling tool calls or notifications miss the window more often than idle bots — but even idle bots are killed sometimes.

Observed Pattern (8 bots over ~1 hour)

| Bot lifetime | Outcome | Notes |
|---|---|---|
| 300s | SIGTERM kill | no ping received before kill |
| 300s | SIGTERM kill | activity present (inbound + tool call) |
| 300s | SIGTERM kill | activity present |
| 301s | SIGTERM kill | activity present |
| 632s+ | killed by user /mcp | ping at uptime 342s (id:2) — survived |
| 632s+ | killed by user /mcp | ping at uptime 347s (id:2) — survived |
| 948s | killed by user /mcp | ping at uptime 338s (id:2) — survived |
| 1000s+ | still alive at posting | pings at id:2 (338s), id:3 (659s), id:4 (961s) — all survived |

Empirically: roughly 50% of bots are killed at the first 5-min mark; survivors get pinged successfully and live indefinitely until the user reconnects.

Wire-protocol Evidence

The 41-byte stdin packet that arrives at the 5-min mark is exactly:

{"method":"ping","jsonrpc":"2.0","id":2}\n

Subsequent pings increment the id (id:3, id:4, …) at ~5-min intervals.

The MCP SDK auto-responds to ping with {"jsonrpc":"2.0","id":N,"result":{}}. Bots that successfully complete this roundtrip survive; bots that don't receive a ping before the timeout (or whose response isn't received in time) are killed via SIGTERM.

The status-bar text "1 claude.ai connector needs auth · /mcp" appears at the same moment as the kill, suggesting the ping check is part of a broader auth/connection re-check cycle that happens to share the kill path.

Effect on Users

• Telegram messages dropped without user awareness (CC marks server failed, bot keeps polling Telegram, but notifications/claude/channel writes are not relayed).
• Manual /mcp reconnect required every disconnect cycle.
• Severely degraded UX for anyone using CC channel mode for remote work.

Relationship to PR #1424 (anthropics/claude-plugins-official)

PR #1424 addresses bot-side reliability bugs (orphan watchdog false-fires, bun install stdout corrupting MCP handshake). Those are real and worth shipping, but they are a different layer — even with #1424 merged, the ping-timeout kill cycle described here would persist whenever the bot is busy enough to miss a ping response window.

Cross-References

• #50607 — Telegram inbound notifications silently drop after /mcp reconnect (this issue describes the same root cause)
• #53617 — StdIO MCP server disconnects after successful tools/call response when progress notifications are emitted
• #43049 — Telegram plugin: inbound notifications not reaching session
• #45985 — Telegram channel MCP server disconnects after 5s, drops messages (mismeasured timing; actual interval is 5 min, not 5s)
• #46334 — Channels (Telegram) silently disabled by tengu_harbor feature flag
• PR #1424 (anthropics/claude-plugins-official) — bot-side reliability fixes, related but addresses a different layer

Suggested Mitigations

1. Increase the ping response timeout for stdio MCP servers, or eliminate the kill-on-miss behavior in favor of explicit notifications/cancelled semantics.
2. Auto-reconnect stdio MCP servers when the connection is closed by the ping-timeout path. Currently, the visible behavior is that stdio servers do not auto-reconnect — the user must manually /mcp.
3. Surface the ping/keepalive failure to the user with a more accurate status message (e.g. "MCP server didn't respond to keepalive in time, killing and respawning") rather than the current "MCP server failed" + auth warning, which is misleading.

Workaround

None reliable. Manual /mcp after each disconnect. A self-restart sidecar (killing the bot's stale poller and spawning a fresh one) is partial — it addresses the kill side but doesn't restore CC's view of the connection.