Dashi Channel — Telegram bridge for Claude Code

dashi-plugin-claude-code

Read in your language: English (this page) · Русская версия →

A Telegram → Claude Code channel plugin. It turns an ordinary, live Claude Code session into a Telegram agent: the bot listens to one or more chats, replies inside the same session, and keeps all the work within your regular Anthropic Max subscription — with no separate SDK billing.

It replaces the deprecated claude -p gateway pattern (a Python daemon that spawned a fresh headless session for every message). Cutover deadline — 2026-06-15 (Anthropic is splitting billing; details in section 13).

Migrating from the old gateway? There is now a doctor — use it. The read-only doctor-dashi-plugin skill diagnoses the whole cutover — workspace placement, hooks (profile-aware), the permission gate and its policy, multichat invariants, webhook bind + token-file hygiene, MCP comms config, allowlist, fleet isolation, and live-session health — and encodes every mistake we already paid for so you don't repeat them. Run it during EVERY migration and whenever the bridge misbehaves: bun skills/doctor-dashi-plugin/scripts/doctor.ts (on a systemd host it autodetects the rest).

And one hard rule: migrate from a Claude Code terminal session, not through Telegram. The migration changes the very bridge that carries your Telegram messages — if it breaks mid-change, the agent you were instructing through Telegram goes silent and can no longer fix itself. Work in a terminal (tmux attach, or a plain claude session on the host); let Telegram be the thing you test, not the thing you work through.

One plugin process = one Telegram bot = one agent. By default it serves a single DM chat (legacy single-session mode). With multichat.enabled turned on, the same bot fans incoming messages out across several per-chat tmux sessions of one identity — see section 3.

Status: in production across a multi-agent fleet. Current release — v1.2.0 (2026-07-10): model-aware context HUD, task pin reality mirror, output formatting polish — see section 15. Versioning and release process: CHANGELOG.md · docs/RELEASING.md. CI: bun test + bun run typecheck must pass clean before merge.

Table of contents

1. How the plugin works and why you need it
2. Personal session + channel tmux, and how to add your user_id
3. Multichat — how it works and why
4. Plugin hooks
5. Interactive commands and channel control: permission prompts, AskUserQuestion, OOB slash commands
6. Terminal mirror — how it works and why
7. Media, audio, and voice-message transcription
8. Session auto-restart — so the link never drops
9. HTML filtering from terminal to Telegram
10. Security — so data never leaks
11. Telegram API rate limits
12. Quick start and documentation
13. Why migrate — the 2026-06-15 deadline
14. Multi-agent — a fleet of agents under one subscription
15. What's new

1. How the plugin works and why you need it

Why

The old architecture (jarvis-telegram-gateway) is a Python daemon that ran claude -p (a headless Agent SDK session) for every Telegram message. Each turn = a new process, a fresh context load, and — after June 15, 2026 — a separate SDK credit billed outside your Max subscription (see section 13).