claude-code - 💡(How to fix) Fix [BUG] [BUG] Plugin [email protected] inbound notification: MCP SDK dispatch resolves OK but Claude Code does not render <channel> block (Windows)

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…

Error Message

Error Messages/Logs

The plugin's MCP SDK reports the notification was dispatched and the Promise resolved successfully. Yet Claude Code shows nothing in the session UI — no <channel> block, no error, no client-side log entry.

Fix Action

Fix / Workaround

[2026-05-20T09:46:01.437Z] pid=99460 ===== server.ts boot ===== [2026-05-20T09:46:01.453Z] pid=99460 MCP stdio transport CONNECTED — ready to send notifications [2026-05-20T09:46:02.055Z] pid=99460 bot.start onStart: polling as @sergeidlin_bot [2026-05-20T09:46:15.548Z] pid=99460 handleInbound ENTER: from=<chat_id> chatType=private text="alfa" [2026-05-20T09:46:15.549Z] pid=99460 gate result: action=deliver [2026-05-20T09:46:15.550Z] pid=99460 about to call mcp.notification: chat_id=<chat_id> content="alfa" [2026-05-20T09:46:15.551Z] pid=99460 mcp.notification call returned (promise dispatched) [2026-05-20T09:46:15.551Z] pid=99460 mcp.notification RESOLVED ok

The plugin's MCP SDK reports the notification was dispatched and the Promise resolved successfully. Yet Claude Code shows nothing in the session UI — no <channel> block, no error, no client-side log entry.


The plugin source (~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.6/server.ts) was instrumented locally with file-based dbg() calls at boot, MCP-connect, handleInbound entry, gate result, and around mcp.notification(). Original backed up as server.ts.backup. The log above is from that instrumentation. Happy to share the full patched server.ts or the access.json contents if useful.

Code Example

Captured by instrumenting server.ts with file-based logging at 4 points (boot, MCP connect, handleInbound entry, gate result, before/after mcp.notification). Output written to ~/.claude/channels/telegram/debug.log:

[2026-05-20T09:46:01.437Z] pid=99460 ===== server.ts boot =====
[2026-05-20T09:46:01.453Z] pid=99460 MCP stdio transport CONNECTED — ready to send notifications
[2026-05-20T09:46:02.055Z] pid=99460 bot.start onStart: polling as @sergeidlin_bot
[2026-05-20T09:46:15.548Z] pid=99460 handleInbound ENTER: from=<chat_id> chatType=private text="alfa"
[2026-05-20T09:46:15.549Z] pid=99460 gate result: action=deliver
[2026-05-20T09:46:15.550Z] pid=99460 about to call mcp.notification: chat_id=<chat_id> content="alfa"
[2026-05-20T09:46:15.551Z] pid=99460 mcp.notification call returned (promise dispatched)
[2026-05-20T09:46:15.551Z] pid=99460 mcp.notification RESOLVED ok

The plugin's MCP SDK reports the notification was dispatched and the Promise resolved successfully. Yet Claude Code shows nothing in the session UI — no <channel> block, no error, no client-side log entry.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

What's Wrong?

The official telegram plugin (telegram@claude-plugins-official v0.0.6) cannot deliver inbound messages to an active Claude Code session on Windows, even though the plugin completes the MCP notification handshake successfully.

Outbound works: bot.api.sendMessage from the plugin succeeds, and the plugin's outbound tools (reply, react, etc.) are discoverable and functional from the session.

Inbound is broken: when a paired user DMs the bot, server.ts's handleInbound() runs, gate() returns 'deliver', mcp.notification({ method: 'notifications/claude/channel', ... }) is called, and the SDK's returned Promise RESOLVES OK — yet no <channel source="telegram"> block ever appears in any open Claude Code session (neither Desktop nor standalone CLI).

This blocks the entire pairing flow: the 6-char pairing code reply (from the pair action) never reaches the user via session, and any post-pairing DM is silently dropped on the receive side. Same symptom across 5 concurrent Claude Code instances; full single-instance "scorched earth" test did not fix it.

What Should Happen?

When the plugin calls mcp.notification with method notifications/claude/channel, the active Claude Code session should render the payload as a <channel source="telegram" chat_id="..." message_id="..." user="..." ts="..."> block, per the plugin's declared capability experimental: { 'claude/channel': {} }.

Error Messages/Logs

Captured by instrumenting server.ts with file-based logging at 4 points (boot, MCP connect, handleInbound entry, gate result, before/after mcp.notification). Output written to ~/.claude/channels/telegram/debug.log:

[2026-05-20T09:46:01.437Z] pid=99460 ===== server.ts boot =====
[2026-05-20T09:46:01.453Z] pid=99460 MCP stdio transport CONNECTED — ready to send notifications
[2026-05-20T09:46:02.055Z] pid=99460 bot.start onStart: polling as @sergeidlin_bot
[2026-05-20T09:46:15.548Z] pid=99460 handleInbound ENTER: from=<chat_id> chatType=private text="alfa"
[2026-05-20T09:46:15.549Z] pid=99460 gate result: action=deliver
[2026-05-20T09:46:15.550Z] pid=99460 about to call mcp.notification: chat_id=<chat_id> content="alfa"
[2026-05-20T09:46:15.551Z] pid=99460 mcp.notification call returned (promise dispatched)
[2026-05-20T09:46:15.551Z] pid=99460 mcp.notification RESOLVED ok

The plugin's MCP SDK reports the notification was dispatched and the Promise resolved successfully. Yet Claude Code shows nothing in the session UI — no <channel> block, no error, no client-side log entry.

Steps to Reproduce

  1. On Windows 11, install Claude Code (reproduced on v2.1.144 and v2.1.98).
  2. /plugin install telegram@claude-plugins-official (installs v0.0.6)
  3. /reload-plugins
  4. /telegram:configure <bot_token> (saved to ~/.claude/channels/telegram/.env)
  5. Verify access.json: dmPolicy=pairing, allowFrom contains your Telegram user_id, pending={}.
  6. From a Telegram client, DM the bot any message (e.g. "alfa").

Expected: <channel source="telegram" ...> block appears in the active Claude Code session within ~1s.

Actual: nothing appears. Plugin-side debug log (added instrumentation) confirms gate()→'deliver' and mcp.notification() Promise RESOLVED ok, but Claude Code session shows no inbound at all.

Already ruled out (none fix it):

  • webhook empty (getWebhookInfo: url="", pending_update_count=0)
  • orphan/zombie bun processes killed (taskkill /F)
  • stale bot.pid removed
  • single-instance scorched-earth test (killed all other claude.exe parents)
  • network/firewall (getMe HTTP 200, IPv6 long-poll Established)
  • pairing state (chat_id confirmed in access.json allowFrom)

Environment:

  • OS: Windows 11 (RU locale)
  • Claude Code: v2.1.144
  • Plugin: telegram@claude-plugins-official v0.0.6
  • Runtime: bun (plugin-bundled)
  • Shell: Windows PowerShell

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.144 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

The plugin source (~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.6/server.ts) was instrumented locally with file-based dbg() calls at boot, MCP-connect, handleInbound entry, gate result, and around mcp.notification(). Original backed up as server.ts.backup. The log above is from that instrumentation. Happy to share the full patched server.ts or the access.json contents if useful.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING