Telegram Plugin: Architecture & Data Flow

⏱ Est. reading time: 3 min Updated on 5/7/2026

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--> CLI

Data 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