telegram plugin: bot polling should be gated by --channels flag (concurrent sessions collide on single Telegram token)

Claude Code version: 2.1.109
Plugin: telegram@claude-plugins-official 0.0.6
OS: Ubuntu 24.04

Problem

The telegram plugin's MCP server (server.ts) unconditionally calls bot.start() every time Claude Code launches with the plugin installed — regardless of whether the session was launched with --channels plugin:telegram@....

Telegram's Bot API allows exactly one getUpdates consumer per token. The plugin has a "replace stale poller" mechanism (server.ts lines 56-69) that SIGTERMs the current bot.pid holder and takes over polling. In a setup where the user has multiple concurrent Claude Code sessions (e.g. a persistent daemon session with --channels, plus SSH sessions from other devices), each spawn steals the poller from the previous one. Whichever session polled most recently consumes inbound messages — but only the --channels session can inject them into its chat. Messages landing on any other session vanish silently.

Reproduction

1. Install the telegram plugin and configure access.json.
2. Start a persistent session with claude --channels plugin:telegram@claude-plugins-official (e.g. inside tmux under systemd).
3. Open a second Claude Code session in another terminal — any flavor (local, SSH, Claude Desktop remote). No --channels flag.
4. Send a Telegram DM to the bot.

Expected: message delivered to the --channels session.
Observed: message consumed by whichever session last spawned its MCP server; if that wasn't the --channels session, message is silently dropped.

Root cause

server.ts lines 993-1032 start polling unconditionally. The plugin has no awareness of whether the parent Claude session was launched with --channels.

Proposed fix

Gate the bot.pid take-over block and the polling IIFE on an env var populated by Claude Code when the session was launched with --channels plugin:telegram@... (e.g. CLAUDE_CHANNELS=plugin:telegram@..., or a per-plugin CLAUDE_CHANNEL_TELEGRAM=1). The outbound tools (reply, react, edit_message) can remain available in every session — they don't require polling.

I'm running a local patch that gates polling behind a custom env var set only in the daemon's systemd unit. Happy to submit a PR if useful.