The telegram channel plugin (claude-plugins-official, v0.0.6) will not stay connected. It connects (stdio, ~130ms), then within ~1s the MCP server process receives SIGINT and exits cleanly — repeatedly. This makes the channel unusable for real-time inbound messages (outbound Bot API is unaffected).
Environment: Claude Code 2.1.181, macOS, bun 1.3.11, node 26.4.0. Launched via claude --continue --channels plugin:telegram@claude-plugins-official.
Log evidence (~/Library/Caches/claude-cli-nodejs/*/mcp-logs-plugin-telegram-telegram/*.jsonl): every restart shows a session id (e.g. f8455381) Successfully connected (transport: stdio), then a different session id (consistently fd4bc484..., the original --continue session) Sending SIGINT to MCP server process → MCP server process exited cleanly.
Investigated / ruled out: Claude Code/bun/node versions unchanged; bun install on start is instant (cached); token + allowlist configured (messages did arrive earlier). One real cause fixed: an orphaned poller (PPID 1) from a hard-killed prior session held the getUpdates long-poll → 409 flap. After killing it and running a single clean session (no orphans, free token verified), the connect→SIGINT cycle STILL occurs.
Hypothesis: --continue + --channels may be the trigger — the session-resume re-initialization tears down the freshly-connected channel MCP (SIGINT), so the channel never stays up. A fresh session (--channels without --continue) may not exhibit this.
Repro: run claude --continue --channels plugin:telegram@claude-plugins-official; observe the telegram MCP connect then get SIGINT'd within ~1s (see mcp-logs).
Suggested fixes: (1) don't SIGINT the channel MCP during --continue resume re-init; (2) more robust stale-poller cleanup; (3) 409 backoff instead of dropping.
The
telegramchannel plugin (claude-plugins-official, v0.0.6) will not stay connected. It connects (stdio, ~130ms), then within ~1s the MCP server process receives SIGINT and exits cleanly — repeatedly. This makes the channel unusable for real-time inbound messages (outbound Bot API is unaffected).Environment: Claude Code 2.1.181, macOS, bun 1.3.11, node 26.4.0. Launched via
claude --continue --channels plugin:telegram@claude-plugins-official.Log evidence (
~/Library/Caches/claude-cli-nodejs/*/mcp-logs-plugin-telegram-telegram/*.jsonl): every restart shows a session id (e.g. f8455381)Successfully connected (transport: stdio), then a different session id (consistentlyfd4bc484..., the original--continuesession)Sending SIGINT to MCP server process→MCP server process exited cleanly.Investigated / ruled out: Claude Code/bun/node versions unchanged;
bun installon start is instant (cached); token + allowlist configured (messages did arrive earlier). One real cause fixed: an orphaned poller (PPID 1) from a hard-killed prior session held the getUpdates long-poll → 409 flap. After killing it and running a single clean session (no orphans, free token verified), the connect→SIGINT cycle STILL occurs.Hypothesis:
--continue+--channelsmay be the trigger — the session-resume re-initialization tears down the freshly-connected channel MCP (SIGINT), so the channel never stays up. A fresh session (--channelswithout--continue) may not exhibit this.Repro: run
claude --continue --channels plugin:telegram@claude-plugins-official; observe the telegram MCP connect then get SIGINT'd within ~1s (see mcp-logs).Suggested fixes: (1) don't SIGINT the channel MCP during --continue resume re-init; (2) more robust stale-poller cleanup; (3) 409 backoff instead of dropping.