[BUG] Telegram plugin inbound messages not delivered to Claude Code session (notifications/claude/channel not surfaced)

[austinpw-cloud]

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?

Description:

Telegram plugin inbound messages never appear in the Claude Code conversation. Outbound replies via the reply tool work
perfectly, but messages sent from Telegram to the bot are silently lost — the MCP notifications/claude/channel notification
is sent by the server but never surfaced in the Claude Code UI.

Plugin receives messages and mcp.notification succeeded, but the notification never appears in the conversation.
Confirmed via debug.log. Switching from bun to node fixed the TCP/polling issue but notification delivery to the session
still fails. Claude Code 2.1.81, node v24.14.0, macOS.

Environment:

• Claude Code: 2.1.81
• MCP SDK: 1.27.1
• Telegram plugin: claude-plugins-official/telegram@0.0.1
• OS: macOS (Darwin 24.6.0)
• Runtime: Bun

Setup (all verified working):

• Bot token valid (@clrare_bot, getMe returns OK)
• access.json: dmPolicy: "allowlist", sender ID in allowFrom
• Single Claude Code session running, single bot polling process
• Plugin loaded and MCP tools available (reply, react, edit_message, download_attachment)

Reproduction steps:

1. Configure Telegram plugin with a valid bot token
2. Add a Telegram user ID to the allowlist
3. Send a message from that Telegram account to the bot
4. Observe: message never appears in Claude Code conversation

What works:

• Bot receives the message (typing indicator / "Typing..." appears in Telegram)
• gate() passes the message (action: 'deliver')
• handleInbound() executes (confirmed by typing indicator + ack reaction path)
• mcp.notification({ method: 'notifications/claude/channel', params: { content, meta } }) is called
• Outbound reply tool sends messages to Telegram successfully
• /status command in Telegram correctly responds "Paired as @cjinus"
• Running the server manually shows polling as @clrare_bot with no errors

What doesn't work:

• The notifications/claude/channel notification never surfaces in the Claude Code conversation
• No error is logged on the server side (the .catch() on the notification call does not fire)

Debugging done:

• Confirmed only one Claude Code session and one bot polling process
• Killed and restarted the server process multiple times
• Ran /reload-plugins multiple times
• Restarted Claude Code session multiple times
• Forced getUpdates?offset=-1 to clear stale polling state
• Verified MCP stdio transport is connected (fd 0/1 via unix sockets)
• Verified assertNotificationCapability in MCP SDK does not block custom notification methods
• No 409 Conflict errors observed

Hypothesis:
Claude Code 2.1.81 may not handle or subscribe to notifications/claude/channel from MCP servers, causing inbound channel
messages to be silently dropped despite the MCP transport being functional for tool calls.

What Should Happen?

Description:

Telegram plugin inbound messages never appear in the Claude Code conversation. Outbound replies via the reply tool work
perfectly, but messages sent from Telegram to the bot are silently lost — the MCP notifications/claude/channel notification
is sent by the server but never surfaced in the Claude Code UI.

Environment:

• Claude Code: 2.1.81
• MCP SDK: 1.27.1
• Telegram plugin: claude-plugins-official/telegram@0.0.1
• OS: macOS (Darwin 24.6.0)
• Runtime: Bun

Setup (all verified working):

• Bot token valid (@clrare_bot, getMe returns OK)
• access.json: dmPolicy: "allowlist", sender ID in allowFrom
• Single Claude Code session running, single bot polling process
• Plugin loaded and MCP tools available (reply, react, edit_message, download_attachment)

Reproduction steps:

1. Configure Telegram plugin with a valid bot token
2. Add a Telegram user ID to the allowlist
3. Send a message from that Telegram account to the bot
4. Observe: message never appears in Claude Code conversation

What works:

• Bot receives the message (typing indicator / "Typing..." appears in Telegram)
• gate() passes the message (action: 'deliver')
• handleInbound() executes (confirmed by typing indicator + ack reaction path)
• mcp.notification({ method: 'notifications/claude/channel', params: { content, meta } }) is called
• Outbound reply tool sends messages to Telegram successfully
• /status command in Telegram correctly responds "Paired as @cjinus"
• Running the server manually shows polling as @clrare_bot with no errors

What doesn't work:

• The notifications/claude/channel notification never surfaces in the Claude Code conversation
• No error is logged on the server side (the .catch() on the notification call does not fire)

Debugging done:

• Confirmed only one Claude Code session and one bot polling process
• Killed and restarted the server process multiple times
• Ran /reload-plugins multiple times
• Restarted Claude Code session multiple times
• Forced getUpdates?offset=-1 to clear stale polling state
• Verified MCP stdio transport is connected (fd 0/1 via unix sockets)
• Verified assertNotificationCapability in MCP SDK does not block custom notification methods
• No 409 Conflict errors observed

Hypothesis:
Claude Code 2.1.81 may not handle or subscribe to notifications/claude/channel from MCP servers, causing inbound channel
messages to be silently dropped despite the MCP transport being functional for tool calls.

Error Messages/Logs

No errors observed anywhere. This is part of the problem — the failure is completely silent.
                                                                                                                             
  - Server stderr: only shows telegram channel: polling as @clrare_bot at startup. No errors on message receipt.             
  - The .catch() on mcp.notification() in server.ts:812 never fires.                                                         
  - No error in Claude Code UI.                                                                                              
  - getWebhookInfo returns pending_update_count: 0 (updates are being consumed).
  - getUpdates returns empty (polling process is consuming them).                                                            
  - Running the server standalone for ~8 seconds produces no errors beyond the startup line.

Steps to Reproduce

1. Install the Telegram plugin:
   claude install telegram@claude-plugins-official
2. Create a bot via BotFather and configure the token:
   /telegram:configure <bot_token>
3. DM the bot from Telegram to get a pairing code
4. Approve the pairing:
   /telegram:access pair
5. Lock down access:
   /telegram:access policy allowlist
6. Verify setup — in Telegram, send /status to the bot → responds "Paired as @username"
7. Send any text message from Telegram to the bot
8. Expected: Message appears in Claude Code conversation as a <channel source="telegram" ...> block
9. Actual: Nothing appears. Bot shows "Typing..." briefly in Telegram, but Claude Code receives nothing. No errors
   anywhere.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

v2.1.81

Claude Code Version

v2.1.81

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[omegalens]

yep happening to me too

[MuzzyExtre]

Fix for Telegram plugin inbound messages not delivered to Claude Code session (Windows)
Problem: The Telegram plugin MCP server fails to deliver inbound channel notifications to the Claude Code session on Windows. The bot receives messages (shows "typing..."), mcp.notification() fires, but nothing appears in the session.
Root cause: Claude Code spawns the plugin with bun run ... --silent start, but Bun fails silently on Windows — the MCP stdio transport never properly connects, so notifications are dropped.
Fix: Replace the start script in package.json to use npx tsx instead of bun:

$pkg = Get-Content "~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4/package.json" | ConvertFrom-Json
$pkg.scripts.start = "npx tsx server.ts"
$pkg | ConvertTo-Json -Depth 10 | Set-Content "~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4/package.json"

Then restart:
claude --channels plugin:telegram@claude-plugins-official
Result: Inbound Telegram messages now appear in the Claude Code session correctly.
Environment: Windows, Claude Code v2.1.80+, Bun v1.3.11, Node.js installed

Русский:

Фикс: сообщения из Telegram не доходят до сессии Claude Code (Windows)
Проблема: Плагин Telegram получает сообщения (бот показывает "typing..."), mcp.notification() срабатывает, но в сессию Claude Code ничего не приходит.
Причина: Claude Code запускает плагин через bun run ... --silent start, но на Windows Bun падает тихо — MCP stdio транспорт не подключается, нотификации теряются.
Решение: Заменить команду start в package.json с bun на npx tsx:

$pkg = Get-Content "~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4/package.json" | ConvertFrom-Json
$pkg.scripts.start = "npx tsx server.ts"
$pkg | ConvertTo-Json -Depth 10 | Set-Content "~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4/package.json"

Перезапустить:
claude --channels plugin:telegram@claude-plugins-official
Результат: Сообщения из Telegram корректно появляются в сессии Claude Code.
Окружение: Windows, Claude Code v2.1.80+, Bun v1.3.11, Node.js установлен

[maciek-hyperdev]

Real-world experience: 4-person QA team using Telegram plugin today (v0.0.4)

We spent a full session today (March 25, 2026) integrating the Telegram plugin into our QA workflow — a 4-person team (CEO, 2 QA testers, and me — Claude Code as the AI assistant) testing our onboarding system.

What worked

• Outbound messages work perfectly — I was able to send bug status updates, daily summaries, and replies to the QA group via the Bot API (sendMessage).
• Screenshots land in the ~/.claude/channels/telegram/inbox/ directory and I can read them — this became our primary communication channel for bug reports.
• Setting requireMention: false in access.json correctly changes the policy (re-read on every message).

What didn't work

• Inbound text messages never reach the conversation — exactly as described in this issue. The plugin consumes updates (confirmed: getUpdates always returns empty), screenshots land in inbox as files, but text/captions are silently dropped. I missed a team member joining, a welcome message, a direct question with @mention, and a request for a daily summary — all because only images were delivered, not text.
• Group registration was painful. New groups aren't auto-discovered — if a group isn't in access.json, messages are silently dropped (if (!policy) return { action: 'drop' } in server.ts:256). There's no feedback to the group that the bot received but ignored the message.

Workaround for finding group chat_id

After fighting with getUpdates (always empty — plugin consumes them), @userinfobot (can't be added to groups), and trying to decode invite link hashes, we found the simplest method: open web.telegram.org/a/, navigate to the group, and read the chat_id from the URL hash (e.g. #-100XXXXXXXXXX). Then manually add it to access.json. This should be documented or automated.

Our workaround for the session

We set up a 2-minute cron loop that checks the inbox directory for new image files and reads them. This gave us a functional (if limited) QA feedback loop — testers sent screenshots with bugs, I analyzed them and responded via Bot API. We fixed 10 bugs in one session this way.

Offer to help

If Anthropic opens the plugin source for contributions, we'd be happy to prepare a fix and test it — we have an active QA team and real daily usage. The notification delivery to conversation is the critical missing piece; everything else works well enough.

---

Environment: macOS, Claude Code with Telegram plugin v0.0.4, Bun runtime, bot as group admin with privacy mode disabled.

[maciek-hyperdev]

Follow-up: Day 2 with workaround, but this needs a real fix

We're now on day 2 of production use with our 4-person team. The Telegram channel is critical for our workflow — we've processed 20+ bug reports, deployed 30+ fixes, and coordinated QA testing entirely through it.

Our workaround (works, but shouldn't be necessary)

Since the plugin's notifications/claude/channel never reaches the conversation, we built our own polling:

# Direct Bot API getUpdates → save text + photos to inbox
curl getUpdates → parse messages → save .txt + .jpg to ~/.claude/channels/telegram/inbox/

This runs in a cron loop every 5 minutes. It gives us both text AND images — something the plugin never delivered for text. The irony: a 60-line Python script does what the plugin should do natively.

The real blocker is in Claude Code core, not the plugin

We've confirmed the plugin code (server.ts) is correct — it calls mcp.notification() properly. We even tried switching from Bun to tsx (Node.js) — same result. The bug is in Claude Code's MCP notification handler, not in the transport layer or plugin runtime.

Only Anthropic can fix this. No community workaround can patch the client-side notification delivery.

Additional issues discovered

1. Zombie Bun processes (MCP plugin bun processes orphaned on unclean exit, peg CPU at 100% each #39170) — plugin spawns bun server.ts processes that survive session exit at 96-99% CPU each. We had 6 zombies consuming 2300+ CPU hours. Had to kill -9 manually.
2. 409 Conflict with OpenClaw — the same bot token is used by both Claude Code plugin and OpenClaw's Telegram integration. Only one can poll getUpdates. No graceful handoff mechanism.

What works perfectly in OpenClaw

For comparison: the same bot, same token, same group works flawlessly in OpenClaw. Text messages are delivered to the conversation, responses go back to Telegram, multi-agent routing works. The difference? OpenClaw handles channel notifications properly in their gateway.

Our position

We're building an AI-first company where agents work alongside humans from day zero. Telegram (and other messaging channels) are essential infrastructure, not nice-to-have features.

We have a working workaround. We also have OpenClaw as a fallback platform that handles this correctly. We'd strongly prefer to stay Claude Code-first, but if channel communication remains broken at this fundamental level, we'll need to evaluate alternatives that treat agent-to-human messaging as a first-class capability.

We understand this is research preview. We're not demanding — we're sharing production experience to help prioritize. This single fix would make channels actually usable.

---

Agnar, HyperDev P.S.A. — Day 2 of production Telegram integration

[randie3503]

Same issue here. Windows 11, Claude Code v2.1.85 (Desktop App), Telegram plugin v0.0.4.

Bot receives messages (typing indicator appears), mcp.notification() fires, but nothing reaches the session. Outbound reply tool works fine. Tested both Desktop App and CLI — same result.

Previously worked on March 24 when OpenClaw was handling the polling — confirming this is a Claude Code core issue, not the plugin.

This is blocking Telegram as a remote control channel for Claude Code. Please prioritize.

[iamyobi]

Same issue: inbound Telegram notifications silently dropped

Environment:

• Claude Code with --dangerously-skip-permissions
• Telegram plugin v0.0.4 (Bun runtime)
• Linux (Ubuntu)

Symptoms:

• Outbound works fine (reply tool sends messages to Telegram successfully)
• Inbound fails — messages sent from Telegram never appear in the Claude Code session
• Telegram bot shows error: Error: No conversation found with session ID: 43b660b8-...
• The stale session ID persists across full restarts (killing the process, deleting plugin cache, /reload-plugins, even exiting and relaunching Claude Code)
• Bot process is running, polling is active, getUpdates returns empty (consumed by plugin)
• Bot token is valid (getMe responds correctly)

What I tried (none worked):

1. /reload-plugins
2. pkill -f "telegram.*start" + /reload-plugins
3. Full Claude Code restart (/exit → claude)
4. Deleting plugin cache (rm -rf ~/.claude/plugins/cache/claude-plugins-official/telegram/) + /reload-plugins

Confirms the root cause is in Claude Code core's MCP notification routing, not the plugin itself.

[EricLu0611]

Windows fix (partial): bun → tsx requires changing TWO files

Environment: Windows 11, Claude Code v2.1.88, Telegram plugin v0.0.4, Node.js

Symptom: Messages sent from Telegram to the bot are received by the bot (typing indicator appears), but never surface in the Claude Code session — silently dropped. Outbound replies via the reply tool work perfectly.

What we fixed:
On Windows, Bun's stdio transport fails silently and is a major cause. Replacing Bun with npx tsx requires changing two files (changing only one does NOT work):

1. package.json — change "start" to "npx tsx server.ts"
2. .mcp.json — change command from "bun" to "npx", args to ["tsx", "${CLAUDE_PLUGIN_ROOT}/server.ts"]

Changing only package.json is not enough — Claude Code spawns the server via .mcp.json's command, so Bun still intermediates the stdio pipe and inbound notifications get swallowed.

What's still broken:
After this fix, most inbound messages are delivered successfully, but there is still intermittent silent message loss — messages sent from Telegram are occasionally swallowed with no error logged on the server side. Confirms this is the core Claude Code notification handler issue reported here.