Telegram channel plugin: MCP server child process not spawned on Linux (v2.1.83)

Bug Description

The Telegram channel plugin (telegram@claude-plugins-official v0.0.4) fails to spawn its MCP server child process when Claude Code starts with --channels plugin:telegram@claude-plugins-official. The --channels flag appears in the process args but no bun child process is created. The server works perfectly when run standalone.

Environment

• Claude Code: v2.1.83
• OS: Debian 12 (Linux 6.17.4-2-pve) — LXC container on Proxmox
• Bun: v1.3.11
• Node.js: v22
• Plugin: telegram@claude-plugins-official v0.0.4 (installed via plugin marketplace)

Steps to Reproduce

1. Install the telegram plugin and configure bot token in ~/.claude/channels/telegram/.env
2. Create ~/.claude/channels/telegram/access.json with an allowlisted user
3. Start Claude Code: claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official
4. Check child processes: pgrep -laP <claude_pid>

Expected Behavior

A bun child process should be running the telegram MCP server (bun run --cwd <plugin_root> --shell=bun --silent start), visible in the process tree alongside other MCP servers (OMC, Playwright, Context7, etc.).

Actual Behavior

No bun/telegram child process exists. Other MCP servers (OMC bridge, Playwright, Context7, Exa, n8n-mcp) spawn normally. One ghost child PID with empty cmdline appeared briefly then died — likely the telegram server crashing on spawn with no stderr output.

No <channel> tags are ever delivered to the conversation. No telegram MCP tools (reply, react, edit_message) appear in the tool list. The Telegram Bot API shows pending_update_count increasing — no consumer is polling.

Diagnostic Evidence

1. Plugin config is correct

# ~/.claude/plugins/installed_plugins.json
"telegram@claude-plugins-official": [{
  "scope": "user",
  "installPath": "~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4",
  "version": "0.0.4"
}]

# ~/.claude/settings.json
"telegram@claude-plugins-official": true

# ~/.claude/channels/telegram/.env
TELEGRAM_BOT_TOKEN=<set>

# ~/.claude/channels/telegram/access.json
{"dmPolicy": "allowlist", "allowFrom": ["<user_id>"], "groups": {}, "pending": {}}

# .mcp.json in plugin dir
{"mcpServers": {"telegram": {"command": "bun", "args": ["run", "--cwd", "${CLAUDE_PLUGIN_ROOT}", "--shell=bun", "--silent", "start"]}}}

2. Server runs perfectly standalone

$ cd ~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4
$ (sleep 8; echo "") | bun run --cwd $(pwd) --shell=bun --silent start 2>&1
# stderr: "telegram channel: polling as @mt121claudebot"
# stderr: "telegram channel: shutting down" (after stdin closes)
# exit code: 0

No errors. Bot polls successfully. Dependencies installed (bun install reports no changes).

3. Child process tree missing telegram

$ pgrep -laP <claude_pid>
32116 node /root/.claude/plugins/marketplaces/omc//bridge/mcp-server.cjs
32122 npm exec @playwright/mcp@latest
32196 npm exec @upstash/context7-mcp
32233 npm exec exa-mcp-server
32275 npm exec n8n-mcp
# NO bun/telegram process

4. Telegram API confirms no consumer

$ curl -s "https://api.telegram.org/bot<token>/getWebhookInfo"
{"ok":true,"result":{"url":"","has_custom_certificate":false,"pending_update_count":6}}

$ curl -s "https://api.telegram.org/bot<token>/getUpdates?limit=1&timeout=1"
# Returns queued messages — confirms no active polling consumer

5. Manual polling workaround confirms bot/token/access are all functional

Created a shell script that polls getUpdates, writes to inbox files, and replies via sendMessage — all works correctly. The bot token, network connectivity, and access config are not the issue.

6. Multiple restarts attempted

• Restarted session 3+ times
• Flushed stale updates via getUpdates?offset=-1 before restart
• Same result each time — no telegram child process spawned

Related Issues

• #37072 — Channel plugin MCP tools not available in session
• #36431, #37498 — Inbound channel notifications not delivered
• #36964 — MCP server dies shortly after startup (Windows)
• #37933 — Inbound messages not delivered to session

This issue is distinct from the above in that the MCP server child process is never successfully spawned (or dies immediately with no output), rather than the server running but notifications not being delivered.

Workaround

Manual polling via shell script + curl for replies. Functional but loses all channel integration benefits (inline <channel> tags, permission relay, etc.).