Telegram plugin: reply-generation listener does not survive/respawn after being killed, breaking DM replies for all configured bots

Summary

After a background process associated with the Telegram plugin channel (visible in ps as claude --channels plugin:telegram@claude-plugins-official) was stopped, Telegram DMs to configured bots are received and acknowledged (a "typing..." indicator appears, and the message is consumed from Telegram's getUpdates queue) but no reply is ever generated or sent. This persisted across a session restart, a full app restart, a full computer restart, and even deleting and recreating the bot from scratch with a brand new token.

Setup

• Two Telegram bots configured on one machine:

1. An existing bot using the default state dir (~/.claude/channels/telegram)
2. A second bot for a different project, configured via a project-level .claude/settings.json with "env": {"TELEGRAM_STATE_DIR": "<custom path>"} pointing to a separate state dir, specifically to avoid credential collision between the two bots

• The second (custom-state-dir) bot never successfully sent a reply, even before anything was killed

Steps to reproduce

1. Configure a Telegram bot via /telegram:configure <token> with a non-default TELEGRAM_STATE_DIR (project-scoped, to avoid clobbering another bot's token at the default path)
2. Pair/approve access via /telegram:access pair <code>, set dmPolicy to allowlist
3. DM the bot on Telegram
4. Observe: "typing..." appears, but no reply is ever sent
5. getUpdates on the bot token shows the message was consumed (queue empty), confirming the plugin's MCP stdio server (bun server.ts) did receive it
6. Restarting the Claude Code session, restarting the desktop app, and restarting the whole computer did not resolve it
7. Separately, two long-lived claude --channels plugin:telegram@claude-plugins-official processes were found running (started at different times, unclear how they were spawned). Killing both (attempting to force a clean respawn) caused a previously-working Telegram bot (the default-state-dir one) to stop responding too — its getUpdates now shows multiple unconsumed messages, confirming nothing is polling it at all anymore
8. No new claude --channels ... process has respawned since, despite session/app/computer restarts, even though the underlying bun server.ts MCP process for at least one bot did restart fine
9. Deleted the affected bot via @BotFather and created a brand new one from scratch (new token, new bot ID, same username). Reconfigured with /telegram:configure, pre-authorized the known sender ID directly in access.json (dmPolicy: allowlist). The bot's built-in hardcoded /start response worked (proving the MCP stdio server and basic bot plumbing is fine), but a real message ("Hi") showed the identical failure: typing indicator appears, message is consumed from getUpdates, but no Claude-generated reply is ever sent, confirmed with a fully-delivered (blue double-tick) message on a clean connection. This rules out both the bot token/identity and network/connectivity as the cause — the issue is specifically in the reply-generation path.
10. Reproduced independently in a second, separate Claude Code session/project on the same machine (different Telegram bot, default state dir config) — same symptom: connector shows "connected", MCP tools load fine, but no <channel source="telegram"> message ever arrives in that session either, confirming this is systemic rather than specific to one project's setup.

Expected behavior

• A Telegram DM to a properly configured + paired bot should receive an actual reply from Claude, not just a typing indicator
• Killing/losing the claude --channels plugin:telegram@claude-plugins-official process should not permanently break reply generation — the app should detect this and respawn it (similar to how the MCP stdio server itself does get relaunched on session/app restart)
• Recreating the bot from scratch should not be necessary, and in this case did not fix the issue either

Impact

• Both Telegram bots on this machine are currently non-functional for replies (messages are received/consumed but never answered)
• No way found from within a Claude Code session to manually respawn the missing listener process (no exposed tool/command found for this)

Environment

• macOS, Claude desktop app, Code tab
• Telegram plugin version 0.0.7 (claude-plugins-official)