Plugins: support singleton mode for plugins that can't run multiple instances (e.g. Telegram polling)

Summary

Plugins that use exclusive external resources (e.g. Telegram bot long-polling) break when multiple Claude Code sessions are active. Each session spawns its own plugin MCP server instance, and they compete for the same resource — in Telegram's case, only one getUpdates consumer is allowed per bot token (409 Conflict).

Environment

• Multiple Claude Code sessions in the same project (tmux panes)
• Spawned Claude subprocesses (system/spawn-claude, worker subtasks) also inherit plugin config and spawn additional instances
• Plugin: telegram@claude-plugins-official (research)

What happens

1. User enables the Telegram plugin in ~/.claude/settings.json (enabledPlugins)
2. Opens multiple Claude Code sessions in the same project
3. Each session + each spawned subprocess starts its own bun server.ts for the Telegram plugin
4. Multiple instances fight over the Telegram polling slot (409 Conflict with backoff/retry)
5. Messages arrive at a random instance — the MCP notification goes to whichever session won the poll, not necessarily the one the user is interacting with
6. No way to enable the plugin for just one session — enabledPlugins is user-global

Observed instance counts

With 10+ Claude sessions and spawned workers, we saw 3-6 simultaneous bot instances at any given time. Manually killing competing instances was a game of whack-a-mole since new sessions and workers kept spawning them.

Feature request

Support a singleton mode for plugins, so that only one instance runs across all sessions. Possible approaches:

1. Plugin manifest singleton: true — plugin declares it needs exclusive access. The first session starts it; others connect to the existing instance or skip it.
2. Lock file — plugin acquires a lock on startup; subsequent instances detect the lock and exit gracefully.
3. Per-session plugin toggle — allow enabling/disabling plugins per-session (not just user-global), so the user can choose which session runs the Telegram bridge.
4. Exclude spawned subprocesses — spawned Claude instances (--session-id, -p with inline prompts) should not inherit plugin config, or should have a flag to opt out.

Option 4 is particularly important — even with a singleton lock, spawned worker subprocesses shouldn't be starting channel plugins at all.

Workaround

Disabled the plugin entirely. No viable workaround for multi-session use.

Labels

Research feedback — the Telegram plugin is marked as research/0.0.1.