Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix MCP stdio transport to plugin silently dies, no disconnect/error logged

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Error Message

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)

Root Cause

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.

Fix Action

Workaround

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

Code Example

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

---

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)

---

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

---

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
RAW_BUFFERClick to expand / collapse

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)

TimestampLast success beforeGapAuto-reconnect?
Apr 17 23:29~23:24~5 minNo
Apr 18 07:51~07:47~4 minNo
Apr 18 14:05~14:00~5 minNo
Apr 18 23:18~23:15~3 minNo
Apr 19 09:03~09:00~3 minNo
Apr 19 23:06~23:03~3 minNo
Apr 20 05:55~05:50~5 minYes (auto)
Apr 20 11:1311:067 minNo (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.

extent analysis

TL;DR

The MCP stdio transport to the Telegram plugin silently breaks multiple times a day, and a manual reconnect is required to restore functionality.

Guidance

  • Investigate the Telegram plugin's stdio transport implementation to identify potential issues that could cause the silent disconnection.
  • Review the Claude Code's connection handling and auto-reconnect mechanism to ensure it is properly detecting and handling broken pipes.
  • Consider adding additional logging or monitoring to detect when the stdio transport breaks and to identify the root cause of the issue.
  • Verify that the autoUpdate setting is correctly disabled in known_marketplaces.json to prevent plugin autoupdate from causing disconnections.

Example

No code snippet is provided as the issue is more related to the interaction between the Claude Code and the Telegram plugin, and the root cause is not clearly identified.

Notes

The issue seems to be specific to the Telegram plugin and the stdio transport, and the root cause is not immediately apparent. Further investigation and debugging are required to identify the cause and implement a permanent fix.

Recommendation

Apply the manual reconnect workaround until a permanent fix is implemented, as it has been shown to be effective in restoring functionality.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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
#response parsing#generation error#database connection#vector store#embedding generation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix MCP stdio transport to plugin silently dies, no disconnect/error logged