Telegram plugin: new sessions without --channels steal polling from active session

Resolved 💬 3 comments Opened Apr 14, 2026 by NBD-MHL Closed Apr 17, 2026

Problem

When enabledPlugins has telegram@claude-plugins-official: true in ~/.claude/settings.json, every new Claude Code session spawns a Telegram plugin (bun process), even sessions started without the --channels flag.

The current PID lock mechanism in server.ts (v0.0.5) uses a "kill old, start new" approach — each new instance kills the previous one and takes over polling. This means:

  1. User starts Session A with --channels plugin:telegram@claude-plugins-official — Telegram works correctly
  2. User opens Session B (no --channels) for unrelated work — Session B's plugin kills Session A's bun process
  3. Session A loses Telegram connectivity entirely
  4. Session B receives Telegram messages but has no --channels context to handle them properly

This is disruptive for users who want a dedicated Telegram session running while working in other sessions.

Expected behavior

If a live Telegram plugin instance is already polling, new sessions should not replace it. The new instance should detect the existing one and exit gracefully, rather than killing the active poller.

Alternatively, sessions started without --channels should not spawn the Telegram plugin at all, even if enabledPlugins is true. The enabledPlugins flag could be treated as "available" rather than "always start", with --channels being the actual activation trigger.

Current workaround

Patching server.ts to change the PID lock logic from "kill old, start new" to "detect existing, exit if alive":

// Original (kills existing instance):
process.kill(stale, 'SIGTERM')

// Patched (exits if existing instance is alive):
process.exit(0)

This patch needs to be reapplied after every plugin update.

Environment

  • Claude Code CLI
  • Telegram plugin v0.0.5
  • ~/.claude/settings.json has "telegram@claude-plugins-official": true

Related

  • #39876 (zombie bun processes with v0.0.4)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗