[Bug] Channels plugin (Telegram) not functioning on Linux - notifications not injected into session

Title

--channels plugin (Telegram) does not spawn or route inbound messages on Linux (works on macOS)

Environment

• Claude Code: v2.1.158 (latest on npm at time of report)
• OS: Debian 13 (headless, x86_64)
• Runtime: bun 1.3.x (/usr/local/bin/bun → ~/.bun/bin/bun), Node 20+
• Plugin: telegram@claude-plugins-official v0.0.6, enabled in ~/.claude/settings.json
• Launch: claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official (inside tmux)
• Reference machine (working): macOS 15, Claude Code v2.1.158, identical plugin/config

Summary

On Linux, the Telegram channel plugin is never spawned by --channels, and when spawned
manually as an MCP server, its notifications/claude/channel notifications are never injected
into the conversation. The exact same configuration works on macOS. Result: channels are
non-functional on Linux.

Expected behavior

Launched with --channels plugin:telegram@claude-plugins-official and the plugin enabled in
settings.json, Claude Code should spawn the channel plugin and inject inbound messages into the
active session — as it does on macOS (where it spawns bun run --cwd … --shell=bun --silent start
natively and routes messages).

Actual behavior

1. Native spawn never happens on Linux. With the plugin enabled in settings.json and

--channels set, no plugin process is created — no bun server.ts, no connection to
api.telegram.org. bun is on the Claude process's PATH and the plugin manifest
(.claude-plugin/plugin.json) declares it as a channel, so discovery should succeed.
On macOS the identical config spawns the plugin immediately.

1. MCP-spawned plugin is not routed. Registering the plugin manually as an MCP server in

~/.mcp.json does make bun server.ts run and poll Telegram correctly: messages are received
and consumed (Telegram getUpdates offset advances, returns empty afterwards). The plugin emits
notifications/claude/channel over its stdout (confirmed in server.ts). But Claude Code
never injects these notifications into the conversation — nothing appears in the session.
The plugin's MCP tools (e.g. reply) work fine via this MCP-server path; only the channel
notifications are dropped.

1. Net effect: inbound channel messages never reach the session on Linux.

Reproduction

1. Install the telegram channel plugin and enable it in ~/.claude/settings.json

("enabledPlugins": { "telegram@claude-plugins-official": true }).

1. Launch: claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official.
2. Observe: no bun plugin process is spawned (pgrep -f "bun server.ts" → empty;

ss -tnp | grep 149.154 → no Telegram connection).

1. As a workaround, add the plugin to ~/.mcp.json as an MCP server. Now bun server.ts runs and

polls Telegram. Send a message to the bot.

1. Observe: the message is consumed by the plugin (getUpdates offset advances) but never appears

in the Claude session.

Tested permutations (all reproduce the failure)

Claude Code v2.1.156 and v2.1.158 × plugin enabled / disabled × native --channels spawn /
manual .mcp.json spawn — every combination fails to inject inbound messages on Linux.

Notes / evidence

• The same plugin + config works end-to-end on macOS (native spawn + inbound routing).
• The plugin's outbound MCP tools (reply, react) do work on Linux when the plugin is

registered as an MCP server — only the inbound notifications/claude/channel path is broken.

• bun is reachable on the Claude process PATH (/usr/local/bin/bun).
• server.ts delivery call: mcp.notification({ method: 'notifications/claude/channel', params: { content, meta } }).

Impact

Blocks running a headless Claude Code "assistant over Telegram" deployment on Linux servers.
Forces a custom bridge (e.g. injecting messages via tmux send-keys + replying via the plugin's
MCP reply tool) to work around the missing native channel routing.

---