Telegram plugin: inbound messages not delivered to session

Same bug for me. Claude Code was able to send messages to the Telegram bot, when I asked it to debug. However, it was not able to receive them. Opus's final conclusion was:

So the bot polls Telegram fine (it delivered the pairing code, and outbound works), but inbound notifications/claude/channel notifications aren't
  surfacing in this session.                                                                                                                        
                                                                                                                                                      
  This is likely a framework-level issue — the MCP notification mechanism for channel messages may not be wired up in this version, or there's a      
  transport issue between the server and the Claude Code harness.                                                                                     
                                                                                                                                                      
  Not much we can debug further from here. I'd suggest reporting this at https://github.com/anthropics/claude-code/issues — the bot is running,       
  polling, and can send, but inbound channel notifications don't reach the conversation.
                                                                                                                                                      
  Want me to try anything else?     

Solved: had to restart Claude with claude --channels plugin:telegram@claude-plugins-official. Claude web knew to suggest this, but the web search in CC didn't find it.

Root cause identified: name mismatch in --channels comparison

Tracked this down via MCP logs on Windows (CLI v2.1.80).

The log entry

{"debug":"Channel notifications skipped: server telegram not in --channels list for this session"}

What's happening

1. The CLI requires tagged style for --channels: plugin:telegram@claude-plugins-official
2. Using untagged (--channels telegram) is rejected with entries must be tagged
3. But the notification matching logic compares the server's self-reported name (telegram) against the full tagged string (plugin:telegram@claude-plugins-official)
4. "telegram" !== "plugin:telegram@claude-plugins-official" → notifications silently skipped

No working combination exists: tagged is required but doesn't match; untagged matches but is rejected.

How to verify

Check the most recent .jsonl in the MCP logs directory:

# Linux/macOS
ls -lt ~/.cache/claude-cli-nodejs/Cache/*/mcp-logs-telegram/

# Windows
ls -lt ~/AppData/Local/claude-cli-nodejs/Cache/*/mcp-logs-telegram/

Look for "Channel notifications skipped" — if it says server telegram not in --channels list, this is the same bug.

(Originally posted on #36442, reposting here as that issue is being auto-closed as duplicate.)

That fix works if you simply weren't using --channels at all. But there's a deeper bug for those who are using the correct flag.

Even with claude --channels plugin:telegram@claude-plugins-official, the MCP log shows:

{"debug":"Channel notifications skipped: server telegram not in --channels list for this session"}

The server registers itself as telegram, but the --channels list stores the full tagged string plugin:telegram@claude-plugins-official. The internal comparison fails because "telegram" !== "plugin:telegram@claude-plugins-official".

And using the untagged form (--channels telegram) is rejected by the CLI with entries must be tagged.

So for some users, the channel is correctly configured but notifications are silently dropped due to this name mismatch. CLI v2.1.80, Windows 11.

Adding another data point. macOS Darwin 25.3.0, Claude Code latest, plugin v0.0.1.

The --channels workaround doesn't fully work either:

| Launch mode | Inbound notifications | MCP tools (reply, react, etc.) |
|---|---|---|
| claude (no flag) | Not delivered | Works |
| claude --channels plugin:telegram@claude-plugins-official | Unknown (MCP broken) | Broken — tools unavailable |

So there's no working configuration right now:

• Without --channels: outbound works, inbound silently dropped (as described in this issue)
• With --channels: MCP server connection breaks, so tools like reply are unavailable — can't even send outbound

This means the name mismatch fix alone won't be sufficient if --channels also breaks the MCP tool registration.

Tested on v2.1.81 (Windows 11) with a new approach: configuring the Telegram plugin as a manual MCP server in .mcp.json and using --channels server:telegram --dangerously-load-development-channels server:telegram.

Result: the CLI accepted the flags, showed the dev warning, I confirmed "local development", and the session started with "Listening for channel messages from: server:telegram, server:telegram". However, the MCP log still shows:

{"debug":"Channel notifications skipped: server telegram is not on the approved channels allowlist (use --dangerously-load-development-channels for local dev)"}

So even with --dangerously-load-development-channels server:telegram, the server is not added to the approved allowlist. The flag is recognized in the UI (confirmation prompt appears) but doesn't propagate to the notification registration system.

This is a different error message from the plugin approach (not in --channels list), but the outcome is identical: inbound notifications are silently discarded.

Summary of all tested configurations on v2.1.81:

| Config | --channels flag | Result |
|--------|------------------|--------|
| Plugin (enabledPlugins) | plugin:telegram@claude-plugins-official | skipped: server telegram not in --channels list |
| Plugin | telegram | CLI rejects: "must be tagged" |
| Plugin | plugin:telegram | CLI rejects: "must be tagged" |
| MCP server (.mcp.json) | server:telegram | skipped: not on approved channels allowlist |
| MCP server + dev flag | server:telegram + --dangerously-load-development-channels server:telegram | Same: not on approved channels allowlist |

{"debug":"Channel notifications skipped: server telegram is not on the approved channels allowlist (use --dangerously-load-development-channels for local dev)"}

+1 Same issue for me (macOS Tahoe 26.0.1 (25A362)) on v2.1.81 with a Discord plugin fork, seems like a race condition between the channel being added to the allow list happening at startup and the allow prompt propagating?

I'm experiencing the same issue which is outbound Telegram replies work but inbound messages don't reach the session.

Same issue on Debian 13

same issue, it's inconsistent. Often the message doesn't go into the session, I can just send it a couple more times and it will go in. only one session running. this issue exists across many platforms (windows, debian, WSL, etc)

Tried patching the plugin's server name to match the tagged --channels format. In server.ts line 336, changed:

{ name: 'telegram', version: '1.0.0' },

to:

{ name: 'plugin:telegram@claude-plugins-official', version: '1.0.0' },

Hypothesis was that the notification router compares the server's self-reported name against the tagged --channels string, and making them match would fix delivery.

Result: No effect. Outbound tools still work fine, but inbound notifications/claude/channel notifications still don't reach the session. Reverted the change.

This rules out a simple string mismatch — the bug is deeper in the framework's notification routing/subscription logic.

Environment: macOS (Apple Silicon), Darwin 25.3.0, Claude Code latest, plugin v0.0.1, enabledPlugins config (no --channels flag).

Thank you for your report — we are currently in the process of triaging MCP-related issues and this one appears to describe the same problem as #36411. To keep the discussion and any fix in one place, we're consolidating into that issue and closing this one. If you have logs, repro steps, or environment details that aren't already covered in #36411, please add them there — it'll help us track this down faster.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.