Sessions without --channels still start the Telegram channel poller, stealing messages from the dedicated --channels session (getUpdates 409)

Summary

Interactive Claude Code sessions (VSCode extension) that are launched without the --channels flag still spawn the Telegram channel poller (bun run --cwd .../telegram/0.0.6 --shell=bun --silent start + child bun server.ts). This conflicts with a dedicated bot session that is running with --channels: the two pollers fight over Telegram getUpdates (409 Conflict), the dedicated session's poller dies, and incoming Telegram messages are silently consumed by (or lost to) the interactive IDE session. The bot appears alive but never answers.

The Channels documentation states that channels start when Claude Code is restarted with the channel flag, implying --channels is the gate. The observed behavior contradicts this.

Environment

• Windows 11 Pro (10.0.26200)
• Claude Code CLI 2.1.222 (dedicated bot session), VSCode extension 2.1.220 (interactive sessions)
• Plugin: telegram@claude-plugins-official 0.0.6, enabled in ~/.claude/settings.json enabledPlugins
• Channel config present in ~/.claude/channels/telegram/ (bot token, access.json)

Setup

A dedicated headless bot session runs 24/7 under a ConPTY host:

claude --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions

Separately, the user opens normal interactive Claude Code sessions in VSCode. Their command line (from Win32_Process) contains no --channels flag:

claude.exe --output-format stream-json --verbose --input-format stream-json
  --max-thinking-tokens 31999 --permission-prompt-tool stdio
  --setting-sources=user,project,local --permission-mode auto
  --include-partial-messages --debug --debug-to-stderr --enable-auth-status
  --no-chrome --replay-user-messages

Observed behavior

Process ancestry captured while reproducing (timestamps local):

1. 18:08:02 — VSCode extension spawns interactive claude.exe (PID 57512, no --channels).
2. 18:08:03 — that session spawns bun run --cwd C:/Users/<user>/.claude/plugins/cache/claude-plugins-official/telegram/0.0.6 --shell=bun --silent start (PID 1460, parent 57512) with child bun.exe server.ts (PID 27388).
3. The dedicated bot session's own poller pair (spawned minutes earlier) is gone shortly after — consistent with losing the getUpdates 409 race and exiting.
4. Messages sent to the bot get no reply. The dedicated session sits at an idle prompt; sendMessage (outbound) still works, so monitoring that only checks outbound delivery sees nothing wrong.
5. Killing the interactive session's poller and respawning the dedicated session restores normal operation immediately.

This reproduced across multiple interactive sessions the same day (a second VSCode session at 18:15 spawned another poller pair after the first one exited). It also matches an earlier two-day incident where two bot machines were silently unresponsive while their host processes looked healthy.

Expected behavior

Sessions launched without --channels should not start channel pollers. Only the session explicitly opted in via --channels should poll.

Impact

Any user who runs a dedicated channel bot and also uses Claude Code interactively on the same machine gets nondeterministic message theft/loss whenever an interactive session is open. Because the poller process exists (just owned by the wrong session), naive liveness checks pass, making this hard to detect.

Workaround

Our bot host now walks process ancestry every 2 minutes, kills any Telegram poller not descended from the dedicated session, and respawns its own poller if dead. This works but is clearly fighting the tooling.

Suggested fix

Gate channel poller startup strictly on the --channels flag (per docs), or provide a supported way (setting/env) to exclude sessions from channel polling.