Telegram-Plugin: Nachrichten erreichen den Channel-Server, werden aber nie in die gebundene Session injiziert

Bug Report: Telegram-Plugin liefert Nachrichten nicht an die gebundene Claude-Code-Session

Datum: 2026-06-24 / 2026-06-25
Betroffene Komponente: Offizielles Telegram-Channel-Plugin (claude-plugins-official/telegram, Version 0.0.6)
Plattform: macOS 15.7.7 (24G720), Claude Code CLI, Telegram-Bot via offiziellem Plugin

Zusammenfassung

Ein über BotFather neu angelegter Telegram-Bot ("claude_bot" / @L1A1_ClaudeBot) wurde per /telegram:configure mit Token eingerichtet und gepaart (Sender-ID korrekt in access.json → allowFrom). Der Plugin-Prozess (bun server.ts) läuft nachweislich und empfängt Nachrichten — Telegram zeigt beim Senden den "is typing…"-Indikator des Bots an. Die Nachricht wird aber nie als <channel source="telegram" ...>-Block in die gebundene Claude-Code-Session injiziert. Es kommt keine Antwort, in keiner getesteten Konfiguration.

Umgebung

• macOS 15.7.7 (24G720), Intel-Hardware, x86_64
• Claude Code CLI, Telegram-Plugin v0.0.6 (claude-plugins-official)
• Token korrekt in ~/.claude/channels/telegram/.env (chmod 600)
• ~/.claude/channels/telegram/access.json: dmPolicy: "pairing", Sender-ID korrekt in allowFrom, pending: {}

Reproduktionsschritte

1. Bot über BotFather anlegen, Token via /telegram:configure <token> speichern.
2. Sender-ID pairen (Code von Bot erhalten, /telegram:access pair <code> ausgeführt) — Sender-ID landet korrekt in access.json.
3. Nachricht an den Bot senden (z. B. "Claude, was ist 2+2?").
4. Telegram zeigt "is typing…" für den Bot an.
5. Keine Antwort kommt an. In der Claude-Code-Session erscheint zu keinem Zeitpunkt ein <channel source="telegram">-Block.

Beobachtete Prozess-/Systemzustände (alle unauffällig)

• bun server.ts (Telegram-Channel-Server) läuft als Kind-Prozess der aktiven claude-CLI-Session, einzelne, nicht-duplizierte Instanz.
• ~/.claude/channels/telegram/bot.pid zeigt korrekt auf die laufende PID.
• access.json: korrekte Sender-ID in allowFrom, kein offener pending-Eintrag.
• settings.json: telegram@claude-plugins-official: true (aktiviert).
• .env: korrekter, gültiger Bot-Token (mit getWebhookInfo/direktem Test gegen die Telegram-API verifiziert — der Bot kann selbst Nachrichten senden, z. B. die Onboarding-Antwort).

Versuchte Fixes (alle ohne Erfolg)

1. /reload-plugins (mehrfach, auch mit --force)
2. claude plugin disable telegram@claude-plugins-official + claude plugin enable telegram@claude-plugins-official
3. Manuelles Beenden des bun server.ts-Prozesses (kill <pid>) — kein automatischer Respawn, MCP-Verbindung (plugin:telegram:telegram) bricht komplett weg und bleibt getrennt, bis sie über das /plugin-Menü manuell neu verbunden wird.
4. MCP-Server-Reconnect über das interaktive /plugin-Menü (Reconnected to plugin:telegram:telegram) — Tools (reply, react, edit_message, download_attachment) werden danach korrekt wieder geladen, Prozess läuft — Problem besteht unverändert weiter.
5. Vollständiger Neustart der claude-CLI-Session (mehrfach, auch nach komplettem macOS-Neustart) — Problem besteht unverändert weiter.

Wichtigster Befund

Der "is typing…"-Indikator beweist, dass die Nachricht den Channel-Server-Prozess erreicht (er reagiert sichtbar darauf). Der Bruch liegt also nachweislich zwischen "Server empfängt Update von Telegram" und "Update wird als Konversationsturn in die gebundene Claude-Code-Session injiziert" — nicht bei Telegram selbst, nicht beim Bot-Token, nicht bei der Pairing-/Zugriffskontrolle.

Vergleichsfall (funktioniert einwandfrei)

Ein zweiter Bot (@l1a1trifecta_bot), umgestellt auf einen eigenen Cloudflare-Worker mit Telegram-Webhook (statt des offiziellen Plugins/Long-Polling), funktioniert seit der Umstellung zuverlässig End-to-End. Das deutet darauf hin, dass das Problem spezifisch im offiziellen Plugin/MCP-Bridging-Mechanismus liegt, nicht in der Telegram-Bot-API selbst.