claude-code - 💡(How to fix) Fix [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.

2. 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.

3. 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 }).
2. Launch: claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official.
3. Observe: no bun plugin process is spawned (pgrep -f "bun server.ts" → empty; ss -tnp | grep 149.154 → no Telegram connection).
4. 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.
5. 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.