Telegram Plugin: Architecture & Data Flow
The Telegram plugin architecture is decentralized compared to the official bridge.
Component Architecture
flowchart LR
subgraph Cloud[Telegram Cloud]
BotAPI[Bot API]
end
subgraph Local[Local Machine]
Server[Bun MCP Server]
Access[(access.json)]
Inbox[(inbox/*)]
CLI[Claude Code CLI]
end
Phone[Telegram Client] <--> BotAPI
Server <--Long Poll--> BotAPI
Server --- Access
Server --- Inbox
Server <--MCP Channels--> CLIData Flows
- Inbound: User sends message → Bot API → Local Server (long-poll) → Validation (access.json) →
<channel>notification to CLI. - Outbound: Agent calls
reply→ Local Server → Bot API → Message arrives at Client. - File Handling: Images are automatically downloaded to
~/.claude/channels/telegram/inbox/because Bot API doesn't allow fetching old images later.
Pairing State Machine
stateDiagram-v2
[*] --> Stranger
Stranger --> Pending: First DM in pairing mode
Pending --> Allowed: /telegram:access pair
Allowed --> Allowed: Subsequent DMs pass
Allowed --> [*]: /telegram:access remove