Telegram channel bridge pairs successfully but never receives incoming messages (Team org account)
Telegram channel bridge pairs successfully but never receives incoming messages (Team org account)
Claude Code version: 2.1.220 (native install, Windows)
Plugin: telegram@claude-plugins-official v0.0.6
Platform: Windows 10, win32-x64
Summary
The Telegram channel bridge (claude --channels plugin:telegram@claude-plugins-official) successfully pairs with a Telegram chat (bot sends the "Paired! Say hi to Claude." confirmation message), but after pairing, incoming messages sent to the bot are never processed by the session. This started immediately after switching the Claude Code login on this machine from a Pro account to a Team/organization account.
Steps to reproduce
- On a machine previously authenticated to a Claude Pro account (channel set up but not working at the time) log out (
claude logout) and log into a Team/organization account instead. - Re-run
/telegram:configureand pair via/telegram:access pair <code>— pairing succeeds, confirmation message is delivered to Telegram. - Run
claude --channels plugin:telegram@claude-plugins-official(with or without--debug). - Send any message (e.g. "hi") to the paired bot from Telegram.
Expected: The message is injected into the Claude Code session and a reply is sent back to Telegram.
Actual: Nothing happens. No response in Telegram, no activity in the terminal. Messages accumulate unread on Telegram's side (confirmed via the Bot API's getWebhookInfo — pending_update_count steadily increases and never drops, e.g. 3 → 6 after two more messages were sent, with no webhook URL configured, implying nothing is long-polling getUpdates).
Diagnosis already performed
- Bot token/config confirmed valid:
getMeon the Bot API succeeds;access.jsonallowlist contains the correct paired chat ID;channelsEnabled: trueandtelegrampresent inallowedChannelPluginsin managed-settings.json;enabledPlugins["telegram@claude-plugins-official"]: truein user settings.json. - Network/sandbox ruled out: Outbound calls to Telegram's API do succeed (the pairing confirmation message is delivered), so there's no network/firewall/sandbox block. Added
sandbox.network.allowedDomains: ["api.telegram.org"]to user settings.json as a test — no change in behavior. - Process stays alive but never polls Telegram: Monitored the running
claude.exe --channels ...process's TCP connections directly (Get-NetTCPConnection) — it never establishes a connection to Telegram's IP range (149.154.x.x / api.telegram.org), only to Anthropic's own API infrastructure andmcp-proxy.anthropic.com(for org-connected MCP servers). - Full
--debuglog reviewed line-by-line: The Telegram plugin's skills load with 0 errors. Org-configured MCP connectors (ClickUp, Didit, Intercom) connect normally. But there is no log line anywhere referencing polling,getUpdates, or any Telegram-specific network activity after initial plugin/skill load — the process just goes idle ([skills] idle — switching poll interval to 30000ms). Notably, the log shows:MCP server "claude.ai Intercom"/"ClickUp"/"Didit": Channel notifications skipped: server did not declare claude/channel capability— i.e. none of this org's connected MCP servers declare theclaude/channelcapability needed to receive channel messages, and no other channel-capable connection is established.
Hypothesis
The inbound message-listening mechanism for the "Channels (experimental)" feature appears to depend on a per-account/org-provisioned resource (possibly surfaced via the [claudeai-mcp] Fetched N servers list) that declares claude/channel capability. Under the Team/organization account, the servers returned are the org's configured business connectors (ClickUp/Didit/Intercom) — not a Telegram channel resource — so there is nothing to deliver incoming messages to. This may be a gap in how Team-tier orgs provision the experimental channels feature, as opposed to individual Pro accounts.
Environment notes
- Account was switched from an individual Pro account to a
claude_team-type organization account on the same machine shortly before this issue appeared. managed-settings.json:{"channelsEnabled": true, "allowedChannelPlugins": [{"marketplace": "claude-plugins-official", "plugin": "telegram"}]}