Telegram channel MCP notifications not surfaced in conversation
Status Fixed / completed
Reported on v2.1.81
Maintainer reply None cached
Activity 5 comments · opened Mar 23, 2026 · closed Apr 12, 2026
Description
Inbound Telegram messages are received by the Telegram channel MCP server and mcp.notification() resolves successfully, but the messages are never injected into the active Claude Code conversation as <channel> tags.
Environment
- Claude Code version: 2.1.81
- OS: macOS (Darwin 24.6.0)
- Plugin:
claude-plugins-official/telegramv0.0.1 - Runtime: Bun
Steps to Reproduce
- Configure the Telegram channel plugin with a valid bot token and allowlisted user ID
- Start a Claude Code session
- Send a message to the bot from the allowlisted Telegram account
- Observe that no
<channel source="telegram">tag appears in the conversation
Observed Behavior
- The bot receives the message (confirmed via grammY polling)
- The access gate passes (
gate result=deliver) mcp.notification({ method: 'notifications/claude/channel', ... })resolves without error- Debug logging confirms "notification sent successfully"
- No
<channel>tag ever appears in the Claude Code conversation - The bot's typing indicator shows in Telegram, confirming the message was processed
Expected Behavior
The notification should be surfaced in the conversation as a <channel source="telegram" chat_id="..." message_id="..." user="..." ts="..."> tag, allowing Claude to read and reply to the message.
Additional Context
- Outbound replies via the
replytool work correctly — messages sent from Claude reach Telegram - Only one bot process is running (no duplicate consumer / 409 conflict)
- The MCP server declares
experimental: { 'claude/channel': {} }capability - Tested across multiple session restarts — same behavior
Debug Log (excerpt)
[timestamp] gate result=deliver from=<user_id> chat=<chat_id>
[timestamp] sending notification chat_id=<chat_id> text=okay, how about now?
[timestamp] notification sent successfully
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
When I ran claude using the proper arguments, it worked as intended. This may be closed, and it is worth noting on the possible duplicates that they may also need to do the same.
This helped me! Thank you
+1 — Team Plan user, same issue on v2.1.86 (macOS Darwin 25.3.0, plugin v0.0.4).
Observed pattern: the first inbound message after session start is delivered as a
<channel>tag. All subsequent messages are silently dropped — even when Claude is idle (waiting for user input).mcp.notification()resolves on the plugin side, but the harness never injects them.Root cause hypothesis: the Claude Code harness does not queue
notifications/claude/channelevents that arrive after the first one has been consumed. The MCP server (plugin) is functioning correctly — grammy polling works,bot.catch()is wired, and no 409 conflicts are present. The drop happens between the MCP notification layer and the conversation injection layer.Additional context: zombie plugin processes from previous sessions can compound this — they consume
getUpdatesoffsets, starving the current session's poller. Killing stalebun run ... telegram ... startprocesses partially mitigated the issue (allowed the first message through) but did not fix the core drop-after-first behavior.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.