Telegram channels plugin keeps consuming getUpdates while the CLI refuses channel registration — permanent inbound message loss

Environment

• Claude Code CLI 2.1.169 (Linux, headless: systemd unit running claude --channels plugin:telegram@claude-plugins-official inside tmux)
• Telegram channels plugin 0.0.6 (bun run .../telegram/0.0.6 start child process)

Summary

When the CLI refuses channel registration at session boot, the telegram plugin process still long-polls getUpdates and advances the offset. Every message sent to the bot during that window is acked to Telegram and dropped — permanent, silent data loss.

Repro

1. Make channel registration fail at boot. Two reliable ways:

• run with DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (both block the statsig feature-gate fetch; the CLI then shows the "Channels are not currently available" toast, and --debug logs Channel notifications skipped: channels feature is not currently available);
• or authenticate with credentials that lack the channels entitlement.

1. Observe the plugin child process is still running and polling (getUpdates returns 409 to any external probe — the poller holds the connection).
2. Send messages to the bot.
3. Fix the gate / restart cleanly. The messages sent in step 3 are gone: never delivered to the session, not retrievable via Bot API (offset advanced).

Expected

If the channel layer refused registration, the plugin should either not start polling, stop polling, or buffer-and-replay on successful registration. Consuming updates it cannot deliver converts a transient config problem into permanent message loss — the worst case for unattended deployments.

Impact

Fleet of unattended headless bots: a config/entitlement hiccup at boot silently eats all inbound traffic until an operator notices.