Telegram plugin: inbound channel notifications silently drop after /mcp reconnect; server also disconnects spontaneously

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Telegram channel plugin (telegram@claude-plugins-official v0.0.6) has two related failures in a single Claude Code
session:

1. After running /mcp to disconnect and reconnect the plugin, the CLI confirms "Reconnected to plugin:telegram:telegram" and

outbound tools (reply, react, edit_message) work again — but inbound Telegram messages never surface in the session as <channel
source="telegram"> tags. The poller consumes them (Telegram's pending_update_count drops to 0 and getUpdates?offset=-1
returns empty) but the Claude session is never notified.

1. The plugin:telegram:telegram MCP server disconnects spontaneously mid-session with no user action, emitting the "MCP server

disconnected" system reminder. Happened twice in one session without any /mcp command, settings change, or signal.

This points at the MCP notification path (notifications/claude/channel, server.ts:980) between the plugin and the Claude
session, not the plugin's allowlist/gate logic.

What Should Happen?

After /mcp reconnect, inbound Telegram messages should arrive in the Claude session as <channel source="telegram"> tags, the
same way they do before a disconnect. The MCP server should also not disconnect spontaneously without user action.

Error Messages/Logs

~/.claude/telegram-bot.stderr.log shows clean startup, no errors:                                                               
  [2026-04-19T02:48:54.190Z] pid=28962 ===== bot starting =====    
  [2026-04-19T02:48:54.482Z] pid=28962 telegram channel: polling as @paulie_claude_bot                                            
                                                                                                                                  
  No "failed to deliver inbound to Claude" errors (server.ts:1000 guard).                                                         
                                                                                                                                  
  Telegram API confirms messages are consumed:                                                                                    
  $ curl .../getWebhookInfo                                                                                                       
  {"ok":true,"result":{"url":"","has_custom_certificate":false,"pending_update_count":0}}
                                                                                                                                  
  $ curl '.../getUpdates?offset=-1&timeout=0'                                                                                     
  {"ok":true,"result":[]}                                                                                                         
                                                                                                                                  
  Session-level: system reminder fires with "The following MCP servers have disconnected" with no corresponding user action in the transcript.

Steps to Reproduce

1. Launch Claude Code with the Telegram channel loaded:

caffeinate -s claude --dangerously-load-development-channels server:telegram --dangerously-skip-permissions

1. DM the bot from an allowlisted sender — confirm inbound works (a <channel source="telegram"> tag arrives in the session).
2. Run /mcp, disconnect plugin:telegram:telegram, then reconnect it. CLI prints "Reconnected to plugin:telegram:telegram".
3. DM the bot again.
4. Expected: <channel> tag arrives. Actual: nothing arrives in the session, but pending_update_count on Telegram's side

drops to 0 (poller consumed it).

Confirmed NOT:

• Stale pollers (only one poller, child of the active session, bot.pid matches)
• Competing Cursor pollers (none present)
• Webhook conflict (no webhook set)
• Allowlist rejection (sender ID matches allowFrom exactly; gate returns action: "deliver")

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.114 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Plugin: telegram@claude-plugins-official v0.0.6
Bun: 1.2.5
macOS: 15.6.1 (24G90)
Relevant plugin source:

• Gate logic (passes cleanly for allowlisted sender): server.ts:249-289
• Inbound delivery to Claude: server.ts:980 method: 'notifications/claude/channel'
• Delivery failure guard (never fires in this bug): server.ts:1000

Key question for maintainers: does /mcp reconnect re-subscribe the host to notifications/claude/channel? If not, that's
likely the inbound-silence bug. Outbound tools coming back while inbound stays dead is consistent with a one-way resubscription
miss.