[BUG] --channels ignored after v2.1.195 update (plugin:telegram@claude-plugins-official)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/51845
2. https://github.com/anthropics/claude-code/issues/46617
3. https://github.com/anthropics/claude-code/issues/55841

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of the linked issues. Key differences:

• #46617 — v2.1.101, MCP server not spawned at all. Fixed in a prior release.
• #51845 — plugin server identifier matching bug. Closed/fixed.
• #55841 — plugin connects but doesn't poll the Bot API. Different symptom.

This issue is a regression introduced specifically in v2.1.195 (June 26, 2026). The setup worked correctly until June 25. The symptom is --channels ignored (plugin:telegram@claude-plugins-official) — the channel never registers, even on a personal Pro plan with no org restrictions and no CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set.

Suspected cause: the v2.1.195 fix for "external plugins enabled only via project .claude/settings.json not requiring explicit install consent on every loader path" introduced a regression in the channels plugin registration path.

Workaround: --dangerously-load-development-channels plugin:telegram@claude-plugins-official alongside --channels.

Please keep this open.

This is not a duplicate-poller or missing-token issue.

Reproduced on v2.1.201 with a clean setup:

• telegram plugin freshly installed
• TELEGRAM_BOT_TOKEN present in ~/.claude/channels/telegram/.env
• only one MCP server instance running (verified via ps, killed the duplicate)

ss -tnp shows the plugin's bun MCP server process has zero established connections to api.telegram.org — it never even opens the long-poll connection. Network path to api.telegram.org is confirmed reachable (curl returns 302) from the same host.

The claude --channels plugin:telegram@claude-plugins-official session itself never renders its first interactive prompt — it appears to hang during MCP server handshake/init, consistent with the connection never being established.

This points to a regression in the MCP-channel initialization path itself, not a config/token/duplicate-process issue on our end.

Root cause found, with a --debug-file log from an interactive --channels session (v2.1.201):

[DEBUG] MCP server "plugin:telegram:telegram": Successfully connected (transport: stdio) in 1742ms
[DEBUG] MCP server "plugin:telegram:telegram": Connection established with capabilities: {...}
[DEBUG] [MCP] Server "plugin:telegram:telegram" connected with subscribe=false
[DEBUG] MCP server "plugin:telegram:telegram": Channel notifications skipped: channels feature is not currently available

Everything upstream of that last line works correctly:

• plugin installed, token present, MCP handshake succeeds, capabilities negotiated fine
• the bot server's own poller is healthy — same log even shows it cleanly taking over from a stale poller (telegram channel: replacing stale poller pid=...), so Telegram-side long-polling is fine

But the client itself explicitly skips wiring up channel notifications with "channels feature is not currently available" — this reads like a feature flag/entitlement gate that's off, not a config or plugin bug. That would explain why --channels silently does nothing regardless of setup: the flag is parsed, the plugin loads, the MCP server connects, and then the client declines to route any channel messages through it.

This is not something fixable client-side/locally — flagging in case it's a gating config issue on Anthropic's end (e.g., disabled post-v2.1.195 for this account/build tier).