Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix telegram plugin: bot polling should be gated by --channels flag (concurrent sessions collide on single Telegram token) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48507•Fetched 2026-04-16 06:58:16
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
dawsmandawsman
Participants
dawsmandawsmangithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×3closed ×1commented ×1

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.

Fix Action

Fix / Workaround

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.

RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The issue can be fixed by gating the bot.pid take-over block and polling in the server.ts file behind an environment variable set only when the Claude Code session is launched with the --channels plugin:telegram@... flag.

Guidance

  • To resolve the issue, modify the server.ts file to check for the presence of a specific environment variable (e.g., CLAUDE_CHANNEL_TELEGRAM) before starting the bot and polling.
  • The environment variable should be set by Claude Code when the session is launched with the --channels plugin:telegram@... flag.
  • The bot.pid take-over block and polling should only be executed if the environment variable is present.
  • The outbound tools (reply, react, edit_message) can remain available in every session without modification.

Example

if (process.env.CLAUDE_CHANNEL_TELEGRAM === '1') {
  // gate the bot.pid take-over block and polling behind this check
  bot.start();
  // ...
}

Notes

  • The proposed fix requires modifying the server.ts file to add a check for the environment variable.
  • The environment variable should be set by Claude Code when the session is launched with the --channels plugin:telegram@... flag.
  • This fix assumes that the CLAUDE_CHANNEL_TELEGRAM environment variable is set correctly by Claude Code.

Recommendation

Apply the workaround by modifying the server.ts file to gate the bot.pid take-over block and polling behind the CLAUDE_CHANNEL_TELEGRAM environment variable, as this will prevent the silent dropping of messages in concurrent Claude Code sessions.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#model loading#dependency error#configuration error#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING