claude-code - 💡(How to fix) Fix [FEATURE] Desktop App: Route incoming Telegram plugin messages to active session (bidirectional support)

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

I run several long-running automation workflows (YouTube content pipeline, customer service triage, ad campaign monitoring) and use Telegram as my "remote control + status inbox" channel — sending commands to Claude Code from my phone when I'm away from my computer, and receiving task completion notifications back.

This works perfectly in CLI mode (claude --channels=plugin:telegram@claude-plugins-official): incoming Telegram messages arrive as <channel source="plugin:telegram:telegram"> tags in the prompt and Claude acts on them immediately.

However, when I use the Desktop App, incoming Telegram messages are never delivered to the active session. Outgoing works (I can use raw HTTP POST as a workaround), but incoming is completely broken — Desktop App's inner CC process spawns and grabs the polling token, but messages never surface in the visible Desktop App conversation.

This forces an unhappy choice:

• Use CLI → lose Desktop App's richer UI (image viewing, sidebar, conversation history)
• Use Desktop App → lose remote-control-from-phone capability, which is the entire point of the Telegram integration

For solo entrepreneurs and small teams running long-running automation workflows, this is a hard blocker.

Proposed Solution

Desktop App should route incoming plugin channel messages into its active session, the same way CLI does with <channel> tags.

Specifically:

1. When a plugin (e.g., claude-plugins-official/telegram) is enabled and Desktop App is active, the App's plugin runtime should receive polling results from the bot API and inject them into the visible conversation as user-equivalent input.

2. The injection format should match CLI's <channel source="plugin:foo:bar"> tag so plugin authors don't need different code paths between CLI and Desktop App.

3. If multiple Desktop App windows / sessions are open, route to the most recently active one (similar to "focused window" routing).

Alternative architecture: expose a documented IPC API that plugin authors can use to push messages into Desktop App's active session, decoupling the plugin polling lifecycle from Claude Code's session lifecycle.

Alternative Solutions

Workarounds I've tried:

1. Hybrid CLI + Desktop App: Keep a CLI window open just for Telegram polling, switch to Desktop App for actual work. Fragile — they fight over the polling token (well-documented in #38098). Requires custom PowerShell Invoke-TGZombieSweep to reclaim polling whenever Desktop App's inner CC grabs it.

2. Outgoing-only via raw HTTP POST: Skip the plugin entirely, use a PowerShell script that POSTs to Telegram Bot API directly. Solves notifications-out, but doesn't help with remote-control-in.

3. Self-hosted Telegram polling daemon (separate process bridging Telegram → file → Claude reads file): Tried this approach. It creates an "incoming black hole" because Claude Code doesn't poll the bridge file actively. Abandoned.

4. Webhook + Cloudflare Tunnel: Considered. Doesn't help because Desktop App doesn't expose any way for external processes to push messages into the active session — same root architectural issue.

None of these match the simplicity of CLI's built-in bidirectional plugin support.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Concrete example from my YouTube content automation workflow:

1. I trigger a long-running task from CLI on Windows: "YT Stage 3, fetch Top 10 transcripts" (this pulls transcripts from 10 YouTube videos, takes ~15 minutes).

2. I leave my desk and go run errands.

3. 10 minutes later, I want to check progress from my phone. From Telegram I send: "進度?" (status check).

4. Expected (works in CLI today): Claude Code receives the message, runs a quick status check, replies via Telegram with current progress.

5. Actual (in Desktop App today): Message is never delivered. I have no way to query Claude Code remotely. I have to wait until I get back to my desk.

6. With this feature: My workflow remains intact regardless of whether I started the task in Desktop App or CLI.

Same pattern applies to customer service triage, ad campaign monitoring, daily content scheduling — any "fire and forget + remote check-in" workflow.

Additional Context

Related issues:

• #38098 (Critical, Open) — Plugin auto-loads in all sessions, multi-process polling contention causes ~50% message loss. This issue's resolution would unblock the current feature request architecturally.
• #37933 / #37256 — Inbound messages show "typing..." but never deliver (related symptom, possibly same root cause).
• #42142 — Desktop App lacks /plugin command for plugin management.
• #40604 — Telegram channel stops receiving messages after first reply.

Environment:

• OS: Windows 11
• Claude Code: Desktop App (latest) + CLI side-by-side
• Plugin: claude-plugins-official/telegram, enabled globally via ~/.claude/settings.json enabledPlugins
• Telegram setup: bot token, allowlist-based DM policy, single allowed user

Why this matters for Anthropic: This is not a niche use case. Telegram's appeal as a Claude Code channel is precisely the asynchronous, mobile-first remote control pattern. Without bidirectional support in Desktop App, the Telegram integration is effectively CLI-only — which significantly limits the audience that can benefit from agentic workflows on long-running tasks.

I'm happy to provide reproduction logs, sanitized config excerpts, or test patches if helpful.