--channels flag prints "Listening for channel messages from …" but does not spawn the channel plugin process (v2.1.126)

Status Fixed / completed

Reported on v2.1.126

Maintainer reply None cached

Activity 3 comments · opened May 4, 2026 · closed May 4, 2026

Summary

Launching claude --channels plugin:telegram@claude-plugins-official reports "Listening for channel messages from: plugin:telegram@claude-plugins-official" in the UI, but no bun run … start child process is ever spawned. Other MCP servers in the same session (e.g. longterm-memory, telegram-mcp) spawn correctly. The result is a half-alive agent: outbound MCP tool calls (telegram - reply) work, inbound TG messages never reach the input loop.

Reproduction

Linux, claude-code v2.1.126.
claude --mcp-config <path> --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions
Observe banner says it's listening.
pstree -p <claude-pid> — no bun run --cwd …/external_plugins/telegram --shell=bun --silent start child.
Send a Telegram message — never delivered.

Expected

A bun run … start grandchild (which then runs bun server.ts) appears as a child of the claude process, as it does in long-running sessions started under earlier point-releases.

Confirmed not to be the cause

No stale bot.pid lock at ~/.claude/channels/telegram/bot.pid.
~/.claude/channels/telegram/.env present with valid TELEGRAM_BOT_TOKEN.
bun is on PATH and the plugin runs cleanly when invoked directly (bun server.ts polls Telegram and emits MCP notifications to stdout).
No errors on stderr.

Workaround

Running the plugin manually (bun server.ts with stdin held open via fifo) confirms it works standalone — but its MCP notifications go to its stdout, which without claude as parent are not ingested.

Environment

claude-code 2.1.126
Linux 6.8.0-110-generic
bun 1.x at ~/.bun/bin/bun
Plugin: claude-plugins-official/external_plugins/telegram

View original on GitHub ↗

3 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

brunz-me · 5 months ago

Closing — root cause was a local environment issue, not a claude-code bug.

The work user's PATH (visible via /proc/<claude-pid>/environ) lacked /home/<user>/.bun/bin/. Claude correctly attempted to spawn the channel plugin via the plugin's .mcp.json (bun run --cwd ${CLAUDE_PLUGIN_ROOT} ...), but the shell couldn't resolve bun and the spawn silently failed — leaving the "Listening for channel messages from …" banner with no actual plugin process.

Fix: ensure bun is on PATH when launching claude. Verified by relaunching with PATH="$HOME/.bun/bin:$PATH" claude --channels … — the bun run and bun server.ts children now spawn correctly.

One mild suggestion if useful: if claude could surface a stderr line when an MCP server's command isn't resolvable on PATH, it would have caught this in seconds instead of hours. Not a bug, just a UX note.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.