[BUG] Telegram plugin auto-loads in all Claude Code sessions, not just --channels sessions

[neuralneeraj]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When the Telegram plugin is installed, every claude -c session (without --channels flag) automatically spawns a Telegram bun process that polls for messages. This causes multiple consumers competing for the same Telegram bot token, resulting in dropped/lost messages.

Steps to reproduce:

1. Install Telegram plugin: claude plugin add telegram@claude-plugins-official
2. Start session A: claude --channels plugin:telegram@claude-plugins-official
3. Start session B: claude -c (no --channels flag)
4. Both sessions spawn separate Telegram bun processes polling the same bot token
5. Messages are randomly delivered to either session — ~50% message loss on the intended session

What Should Happen?

Expected behavior:
Only sessions explicitly started with --channels plugin:telegram@claude-plugins-official should spawn the Telegram plugin process. Plain claude -c sessions should not load channel plugins.

Actual behavior:
All sessions load installed plugins regardless of --channels flag. Each spawns its own bun server.ts process for the Telegram plugin, creating competing consumers on the same bot token.

Workaround:
Manually kill the extra bun/server.ts processes spawned by non-channel sessions.

Impact: Critical for Telegram users — messages are silently lost with no error indication.

Error Messages/Logs

Steps to Reproduce

1. Install Telegram plugin: /install telegram@claude-plugins-official
2. Start terminal A: claude --channels plugin:telegram@claude-plugins-official
3. Start terminal B: claude -c (no --channels flag)
4. Run: ps aux | grep "server.ts" — shows TWO telegram bun processes
5. Send a Telegram message — it randomly goes to terminal A or B
6. ~50% of messages silently lost on the intended session

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.81 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[bujosa]

same happen with me

[liysx]

I'm also experiencing this issue. After exiting Claude Code, the Telegram plugin's bun process is not terminated and keeps running until CPU hits 100%.

Environment:

• Claude Code version: 2.1.81
• Telegram plugin version: 0.0.4
• Terminal: Ghostty
• Hardware: Mac mini M4 Pro
• OS: macOS

The orphaned bun server.ts process from the Telegram channel plugin persists after session exit and gradually consumes all available CPU resources.

[SG5]

running until CPU hits 100%.

@liysx try to update to 2.1.83

[neuralneeraj]

@SG5 Still the same issue

[liysx]

The core issue persists on v2.1.83 — every new Claude Code session still spawns a Telegram plugin process regardless of whether --channels was passed.
Each bun process now terminates properly when its parent session exits. The number of running Telegram plugin processes matches the number of active sessions exactly.
The practical impact remains: multiple competing consumers on the same bot token cause messages to be randomly routed to unintended sessions, resulting in probabilistic message loss.

[rzblues]

Confirmed + Root Cause + Reference Implementation

Reproducing this on macOS 15 (Darwin 25.3.0 arm64) with Claude Code v2.1.85 + VSCode extension. The VSCode sidebar panel also loads the Telegram plugin even without --channels, causing the same competing-consumers problem.

Root cause (from source inspection)

From cli.js, the plugin loading path (Ol_()) reads enabledPlugins from ~/.claude/settings.json at startup and unconditionally starts the MCP server for every matching plugin — regardless of whether --channels was passed. The --channels flag is a separate subsystem: it only registers an already-running MCP server for inbound channel notifications. So:

• enabledPlugins: true → every CC instance starts the bot (polling begins)
• --channels → marks that instance as the one that should handle inbound pushes

Both are required for the channel to work, but the decoupling means every instance starts polling, even though only one should.

Workaround (better than killing processes)

Add "telegram@claude-plugins-official": false to a project-level .claude/settings.local.json in the working directory used by your non-channel instances (e.g. your VSCode project root). This overrides the global enabledPlugins for that instance only.

Reference implementation: OpenClaw

OpenClaw (github.com/openclaw/openclaw) — an open-source AI messaging gateway that also runs Telegram bots — handles this exact problem cleanly. Their approach (extensions/telegram/src/):

1. Update offset persistence (update-offset-store.ts): stores { lastUpdateId, botId } to disk, validates botId on load to reject stale offsets from a different token
2. In-flight deduplication (bot.ts): tracks which update IDs are currently being processed; only advances the "safe watermark" below the smallest in-flight ID — prevents skipping updates under concurrent processing
3. In-memory dedup (createTelegramUpdateDedupe()): secondary guard within a session

Result: multiple instances can safely share the same bot token. Each receives every update, but deduplication ensures each is processed exactly once — no message loss.

This is the pattern I'd suggest as a reference for fixing the plugin-level conflict here.