Telegram channel MCP server dies shortly after startup on Windows
Telegram channel MCP server dies shortly after startup on Windows
Environment
- Claude Code: v2.1.81
- OS: Windows 11 Pro (10.0.26200)
- Shell: Git Bash (MINGW64)
- Bun: 1.3.11
- Node: v24.14.0
- Plugin:
telegram@claude-plugins-official(v0.0.1, commit 61c0597779bd) - Auth: claude.ai (Pro/Max, not Team/Enterprise)
Description
The Telegram channel plugin's MCP server starts and processes initial messages, then silently dies. After the crash, the bot stops responding to Telegram messages entirely. Claude Code continues running normally — only the channel server process is gone.
Steps to reproduce
- Install the Telegram plugin:
/plugin install telegram@claude-plugins-official - Configure the token:
/telegram:configure <token> - Start with channels:
claude --channels plugin:telegram@claude-plugins-official - Startup banner confirms:
Listening for channel messages from: plugin:telegram@claude-plugins-official - DM the bot on Telegram — it responds with a pairing code (server is alive)
- Approve the pairing:
/telegram:access pair <code> - Wait ~2-3 minutes
- Send another message on Telegram — no response
Diagnosis
After the bot stops responding, calling the Telegram Bot API directly confirms no one is polling:
curl "https://api.telegram.org/bot<token>/getUpdates?limit=1&timeout=0"
# Returns pending updates (200 OK, result array non-empty)
# If the server were polling, this would return 409 Conflict or empty resultstasklist | grep bun shows no bun processes running — the server process has exited.
Manual run works fine
Running the server manually with stdin held open works correctly and maintains polling indefinitely:
cd ~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.1
sleep 60 | bun server.ts 2>&1
# Output: "telegram channel: polling as @MothsLightbot"
# Server stays alive and responds to messages for the full 60 secondsThis suggests the issue is in how Claude Code manages the child process stdio pipes on Windows, not in the server itself.
Expected behavior
The channel MCP server should remain running for the lifetime of the Claude Code session, maintaining the Telegram long-polling connection.
Actual behavior
The server starts, processes a few initial messages (pairing codes), then exits silently. No error output visible in the terminal. The --channels startup banner remains, but the underlying bun process is gone.
Possible cause
The server uses StdioServerTransport from @modelcontextprotocol/sdk. On Windows, stdio pipe handling for child processes may differ from Unix — if the pipe buffer fills or a write fails, the transport closes and the server interprets it as a shutdown signal. The server's shutdown handler (telegram channel: shutting down) fires, and the async bot-polling IIFE is canceled.
Workaround
None found. The server cannot be run standalone because it requires the MCP stdio connection to Claude Code to deliver channel events.
7 Comments
Update: Channel works, but only intermittently
After further debugging, the channel does work — but the server process appears to die and restart unpredictably. Key findings:
Root cause: zombie server processes
When multiple Claude Code sessions exist (even without
--channels), each session spawns its own Telegram MCP server. Since Telegram'sgetUpdatesAPI is single-consumer, only one process can poll at a time. The others get409 Conflictand retry.The critical issue: a session without
--channelsstill spawns the plugin's MCP server (for tool access), which polls Telegram and consumes messages — but since--channelsisn't enabled, it silently drops the inbound notifications. This creates a race condition where the wrong server wins polling and messages vanish.Evidence
tasklistshowed 2 Telegram plugin servers from 2 different Claude Code sessionswmic processconfirmed both had the same command:bun run --cwd .../telegram/0.0.1 --shell=bun --silent startgetUpdatesreturned 0 pending updates (someone was consuming), but no channel events arrivedSuggested fix
The plugin's MCP server should only start Telegram polling when the session has
--channelsenabled for that plugin. Currently it appears to poll unconditionally, which means any session with the plugin installed will compete forgetUpdates, even if channel message delivery is disabled.Environment (unchanged)
telegram@claude-plugins-officialv0.0.1Environment
| Field | Value |
|-------|-------|
| OS | Windows (with Avast Antivirus) |
| Claude Code (last known working) | 2.1.85 (unconfirmed if downgrade fixes issue) |
| Claude Code (current) | 2.1.88 |
| Plugin |
telegram@claude-plugins-officialv0.0.4 || Bun | Installed via WinGet (
Oven-sh.Bun) |Error
What Happened
bun.exefromC:\Users\pc\AppData\Roaming\npm\node_modules\bun\bin\Fixes Attempted
Oven-sh.Bun).claudeplugin foldersNone of the above resolved the issue.
Posting this for anyone who runs into the same issue. I had
telegram@claude-plugins-officialfailing to connect as an MCP server on Windows. Here's what fixed it:Root Cause
Stale project-level settings files (
.claude/settings.jsonand.claude/settings.local.json) were conflicting with the user-scoped plugin installation, and leftover plugin cache files were blocking the reinstall.Steps
1. Delete conflicting project-level settings (if they exist in your project directory)
.claude/settings.json.claude/settings.local.json2. Uninstall the plugin
Launch Claude Code from your user config directory:
Then run:
Exit Claude Code.
3. Confirm the MCP is gone
4. Clear and recreate the plugin cache
5. Reinstall the plugin
Launch Claude Code again from
C:\Users\<YourUser>\.claude:Choose "Install for you (user scope)".
6. Verify and test
Telegram should show as connected. To test:
---
Environment: Windows 10/11, Claude Code, user-scoped plugin install
Confirming the v0.0.1 zombie/race-condition diagnosis applies to v0.0.6 too — and a clean re-setup makes it stable
Adding data points from a fresh test today (2026-04-29) on Windows 11 Pro:
TL;DR
After a clean re-setup with a dedicated bot and killing all stale plugin/Bun processes, the plugin works reliably.
bun.exePID stayed alive >36 min through 4 spaced pings (one with a 15-min idle gap). No silent death at the 2-3 min mark that I previously observed earlier the same day.The "silent death at 2-3 min" turned out to be the zombie/409 race
Earlier today I was seeing the exact symptom @AhSnahp described in the v0.0.1 update: the channel stops delivering messages even though the process is alive. Diagnosis matches:
claude --channels plugin:telegram@claude-plugins-officialsession left an orphanedbun.exepolling Telegram after I closed the terminal.getUpdates(long-polling stdlib workaround) immediately failed with409 Conflict: terminated by other getUpdates request; make sure that only one bot instance is running.Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'claude-plugins.*telegram|bun.exe.*0\.0\.6' }showed the orphan PIDs from a Claude session that had been closed hours earlier.So the "muere silenciosamente a los 2-3 min" symptom may often be misdiagnosed — what's really happening is that another orphaned plugin process is winning the
getUpdatesrace, and the new session never sees its messages.Reproduction of the working state
Stop-Process -Name bun -Force(or otherwise kill all stalebun.exefrom prior sessions)409from the V1 bot still being polled by a zombie elsewhere)~/.claude/channels/telegram/.envupdated with the new tokenclaude --channels plugin:telegram@claude-plugins-official/telegram:configure— token loaded/telegram:access pair <code>then/telegram:access policy allowlist— chat closedStability log
| Ping | Madrid time | bun.exe PID | Uptime | Result |
|---|---|---|---|---|
| 1 | ~12:55 | 2572 | ~5 min | OK |
| 2 | 13:04 | 2572 | 15.1 min | OK |
| 3 | 13:13 | 2572 | ~24 min | OK |
| 4 (after 15-min idle gap) | 13:25 | 2572 | 36.6 min | OK |
Same PID throughout. No restarts. Same process handled the 15-min idle window without dying.
Suggested next steps for this issue
This may be ready to close as resolved-via-process-fix, but two things would help users hit by this in the wild:
/telegram:configureoutput. Something like: "If you've previously run the plugin in another session, runStop-Process -Name bun -Force(Windows) orpkill bun(macOS/Linux) before starting--channels. Otherwise an orphaned poller will silently consume your messages."--channelsenabled for that plugin, not just when the plugin is installed. That would eliminate the silent-orphan class of bug entirely.Environment
telegram@claude-plugins-officialv0.0.6~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.6/Happy to dig further if useful.
Update — overnight stability test passed (18+ hours uptime, no restarts)
Following up on my previous comment with the long-form data. The bot I configured at 12:49 Madrid time on 29-Apr-2026 with a clean setup is still running on the same PID at 07:02 Madrid on 30-Apr-2026 — that's 18.2 continuous hours without the Bun process dying or restarting.
Evidence
Activity during that window
I sent 6+ messages spaced across the period, including:
All received and responded by Claude via Telegram. No 409 conflicts, no silent message loss, no zombie issues during this run (the zombie issue from my previous comment was caused by orphan processes from a prior session that I'd killed before this test).
Implication for this issue
In my Windows 11 Pro setup, Issue #36964's "muere a los 2-3 minutos" symptom is no longer reproducible with v0.0.6 + clean setup. The plugin is functionally stable for long-running interactive sessions.
I'm moving it to ADOPTAR internally and using it as the primary input channel for some Claude Code sessions. Long-polling Python (the workaround I'd been using) stays in production for scripted monitors that don't want the
--channelsflag, but for interactive sessions the plugin is now my preferred path.Happy for the maintainers to close this issue if my data point is sufficient. If others on Windows want to verify before closing, the clean-setup steps that made it work for me are documented in alanfong93's earlier comment in this thread.
Environment (unchanged from previous comment)
telegram@claude-plugins-officialv0.0.6~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.6/Thanks for the report. This is fixed and will ship in an upcoming release. The Windows process cleanup path now uses a process-tree-aware kill so the stdio MCP server is no longer terminated unexpectedly during session lifecycle transitions.
If you still see the server exit early after updating, please open a new issue with the version number and the contents of
~/.claude/logs/mcp-*.logand we will take another look.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.