--channels plugin:telegram starts but never spawns the plugin's MCP server (bun) on Windows — bot silently never responds

Environment:

• OS: Windows Server 2025 Datacenter (10.0.26100)
• Claude Code version: 2.1.220
• Plugin: telegram@claude-plugins-official v0.0.6
• Runtime: bun 1.3.14 (installed at ~/.bun/bin/bun.exe, resolvable via PATH)

Summary:
Running claude --channels plugin:telegram@claude-plugins-official (with TELEGRAM_BOT_TOKEN set in the process environment) starts and stays alive indefinitely, but the plugin's MCP server process (bun run --cwd <plugin_root> --shell=bun --silent start, per the plugin's .mcp.json) never spawns as a child process. As a result the bot never calls Telegram's getUpdates, so incoming messages sit unconsumed indefinitely (getWebhookInfo shows a growing pending_update_count that never drains) and the bot never responds.

Steps to reproduce:

1. Configure the telegram channel (/telegram:configure) with a valid bot token.
2. Launch: claude --channels plugin:telegram@claude-plugins-official
3. Send a message to the bot on Telegram.
4. Poll https://api.telegram.org/bot<token>/getWebhookInfo — pending_update_count increases and never returns to 0.
5. Inspect child processes of the claude.exe process (e.g. Get-CimInstance Win32_Process | Where ParentProcessId -eq <pid>) — no bun.exe process ever appears as its child.

What I tried (all failed to produce a working bot):

• Launching via a scheduled task running a wrapper script (start-bridge.ps1) that redirects all output (*>> logfile) — this actually crashes immediately with Error: Input must be provided either through stdin or as a prompt argument when using --print, even though --print is never passed. Seems to be triggered whenever stdout is redirected/non-TTY.
• Launching interactively in a real console window (no redirection) — process starts and stays alive with no crash, but never spawns the bun MCP server child process, confirmed over multiple runs and wait periods (45-50s+).
• Wiping the plugin's node_modules and bun.lock and letting it do a clean bun install — reinstall completed cleanly (250 packages), but behavior is identical: no bun child process, no updates consumed.
• Manually running the plugin's own start command (bun run --cwd <plugin_root> --shell=bun start) directly in a shell — this does work and bun starts fine, so bun itself and the plugin's server.ts are not the problem; the issue appears to be specifically in how claude.exe's --channels mode spawns/manages this child process on Windows.

Expected: The channel process should spawn the plugin's MCP server as a child process and keep polling Telegram for updates.

Actual: The outer claude.exe process stays alive (some background CPU usage, not fully hung) but never spawns the MCP server child, so the bot never processes any Telegram messages.