MCP notifications/claude/channel notifications not delivered to session (Telegram plugin)

Status Closed — not planned
Reported on v2.1.80
Maintainer reply ✓ Yes — localden
Activity 6 comments · opened Mar 20, 2026 · closed May 5, 2026
💡 Likely answer: A maintainer (localden, collaborator) responded on this thread — see the highlighted reply below.

Bug Description

MCP notifications with method notifications/claude/channel are not being delivered to the Claude Code session, even though the notification is sent successfully by the MCP server.

Evidence

I have confirmed through debugging that:

  1. MCP notification is sent successfully - Log shows:

``
2026-03-20T21:06:23.419Z attempting notification for chat_id=1618126757, text="Can u see this Monsieur..."
2026-03-20T21:06:23.422Z notification sent successfully
``

  1. MCP connection is working - Outbound MCP tools (reply, react, edit_message) work correctly. I can send messages TO Telegram.
  1. MCP server is properly connected - Process tree confirms the MCP server is a child of the Claude Code process.
  1. Inbound notifications are NOT delivered - The <channel source="telegram"> messages never appear in the session, despite the notification being sent.

Technical Details

Environment

  • Claude Code version: 2.1.80
  • Telegram plugin version: 0.0.1
  • MCP SDK version: 1.27.1
  • OS: macOS (Darwin 25.3.0)

MCP Server Configuration

{
  "mcpServers": {
    "telegram": {
      "command": "bun",
      "args": ["run", "--cwd", "...", "--shell=bun", "--silent", "start"]
    }
  }
}

Server Capabilities Declaration

capabilities: {
  tools: {},
  experimental: { 'claude/channel': {} }
}

Notification Format

mcp.notification({
  method: 'notifications/claude/channel',
  params: {
    content: text,
    meta: {
      chat_id: string,
      message_id: string,
      user: string,
      user_id: string,
      ts: string
    }
  }
})

Process Tree (confirmed MCP server is child of Claude Code)

claude --model glm-5:cloud (PID 37304)
└── bun run ... start (PID 37312)
    └── bun server.ts (PID 37317)

Debug Log

2026-03-20T21:06:23.419Z attempting notification for chat_id=1618126757, text="Can u see this Monsieur..."
2026-03-20T21:06:23.422Z notification sent successfully

Expected Behavior

When the MCP server sends a notifications/claude/channel notification, Claude Code should deliver the message content to the session as a <channel source="telegram"> message, as documented in the plugin's instructions.

Actual Behavior

The notification is written to stdout by the MCP server (confirmed by "notification sent successfully" log), but Claude Code does not process/forward the notification. The session never receives the <channel> message.

Additional Context

  • The Telegram plugin is installed and enabled via enabledPlugins in settings.json
  • Outbound MCP tools work correctly (reply, react, edit_message)
  • The MCP server uses StdioServerTransport (stdin/stdout)
  • User sees "typing..." indicator in Telegram (bot receives messages and processes them)
  • Only inbound channel notifications fail

Possible Root Cause

Claude Code may not have a handler registered for the notifications/claude/channel notification type. The MCP SDK's _onnotification method silently ignores notifications without handlers:

_onnotification(notification) {
    const handler = this._notificationHandlers.get(notification.method) ?? this.fallbackNotificationHandler;
    // Ignore notifications not being subscribed to.
    if (handler === undefined) {
        return;
    }
    // ...
}

Steps to Reproduce

  1. Install telegram plugin: /plugin install telegram@claude-plugins-official
  2. Configure bot token: /telegram:configure <token>
  3. Enable plugin in settings.json: "enabledPlugins": { "telegram@claude-plugins-official": true }
  4. Start session with MCP config or enabled plugin
  5. Send a message to the Telegram bot
  6. Observe: Bot sends "typing..." but notification never arrives in session

Workaround

None currently. Outbound messages work, but inbound messages cannot be received.

View original on GitHub ↗

6 Comments

shersingh7 · 6 months ago

Policy Compliance Confirmation

This is a legitimate, sanctioned use case. The Telegram MCP plugin:

  1. Uses MCP as intended - Model Context Protocol was created by Anthropic specifically for connecting AI to external tools and context. 88M+ monthly SDK downloads, 18,000+ servers.
  1. Correct authentication - Using OAuth tokens with Claude Code (not routing through a third-party product). Per Claude Code Legal: "OAuth authentication is intended exclusively for Claude Code and Claude.ai."
  1. Follows MCP Best Practices - Clear tool descriptions, proper documentation (README, ACCESS.md), access control (pairing/allowlist), safety guardrails against prompt injection.
  1. Meets chatbot disclosure requirement - Per Anthropic Usage Policy: "All consumer-facing chatbots and external-facing interactive AI agents must disclose to users that they are interacting with AI rather than a human." The Telegram bot username ("ClaudeCodeDavid_bot") inherently identifies it as a bot.
  1. No prohibited activities - Not bypassing security, creating malware, spam at scale, or misinformation.

This bug affects a core MCP use case and should be prioritized for the channel/notification delivery feature.

laurence-gif · 6 months ago

Same issue here — Claude Code 2.1.81, macOS, Telegram plugin v0.0.1. Outbound reply/react/edit tools all work. Inbound mcp.notification() with notifications/claude/channel fires successfully but never surfaces as <channel> tags. Confirmed bot is polling, gate passes, no webhook conflicts. +1 for a fix.

babel-stack · 6 months ago

Confirming the same issue on a completely different stack: NixOS, Linux 6.19.5, Node.js v24.13.0, running the Telegram plugin via npx tsx (not bun — CPU lacks AVX instructions). Tool calls (reply, react, edit_message) work perfectly; only inbound notifications/claude/channel are silently dropped. This rules out bun-specific causes.

babel-stack · 6 months ago

Full details of our diagnosis and environment in #37633 (closed as duplicate of this issue).

localden collaborator · 5 months ago

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.

github-actions[bot] · 3 months ago

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.