Telegram channel plugin 0.0.6: polling never starts under plugin runtime (repro across Claude 2.1.207-2.1.210 + Bun 1.3.11/1.3.14; standalone works) — follow-up to locked #36606

Same bug as the (locked) #36606, reproduced on plugin 0.0.6 with new elimination data that narrows the cause to the plugin runtime's spawn context.

Reproduced on plugin 0.0.6 (so the all-errors retry loop that 0.0.6 added does not cover this) with extensive elimination testing. Windows 11 Pro 10.0.26200, native CLI install.

Same fingerprint: server process alive, MCP tools work, Channel notifications registered in the client log — but grammY polling never starts: no polling as @<bot> stderr line, no retry/error lines, and the bot's getUpdates queue grows unboundedly (getWebhookInfo.pending_update_count stuck at 18 for hours). A one-shot external getUpdates probe (no offset) returns data instantly instead of 409 — nothing is holding a long-poll, so bot.start() dies before its first successful getUpdates.

Eliminated (each tested tonight):

• Claude Code version: identical behavior on 2.1.207, 2.1.209, 2.1.210 (fresh server spawn each; auto-updater disabled during the bisect).
• Bun version: identical on Bun 1.3.11 and 1.3.14.
• Machine/network/env: standalone bun -e "fetch('https://api.telegram.org')" → 200 in <1s; standalone grammY new Bot(token); await bot.init() from the plugin directory → init OK in 430 ms; no *_PROXY/NODE_OPTIONS env in the session environment Claude propagates to children.
• Config gates: bot is a group member, privacy mode disabled (getMe.can_read_all_group_messages: true), session launched with --channels plugin:telegram@claude-plugins-official, access.json valid.

One consistent oddity worth a look: ~30 s after every spawn the client log shows
notifications/claude/channel/permission: <5-char-id> → allow (matched pending) — the permission handshake completes, yet polling still never begins. The dead server also holds 2-3 ESTABLISHED but idle TCP connections to api.telegram.org:443 (149.154.166.110 + the IPv6 endpoint), which looks like fetch requests that were sent (or half-sent) and never complete — consistent with bot.init()/getUpdates hanging forever inside the plugin-spawned process specifically (grammY has no default request timeout, so a hung fetch produces exactly this silent no-error state).

Since it reproduces across Claude versions and Bun versions but never standalone, the delta seems to be the plugin runtime's spawn context (stdio wiring / bun run --silent start wrapper) rather than the plugin code, Bun, or the network. Happy to run diagnostics on a debug build if useful.