configure

# /telegram:configure — Telegram Channel Setup Writes the bot token to `~/.claude/channels/telegram/.env` and orients the user on access policy. The server reads both files at boot. Arguments passed: `$ARGUMENTS` --- ## Dispatch on arguments ### No args — status and guidance Read both state files and give the user a complete picture: 1. **Token** — check `~/.claude/channels/telegram/.env` for `TELEGRAM_BOT_TOKEN`. Show set/not-set; if set, show first 10 chars masked (`123456789:...`). 2. **Access** — read `~/.claude/channels/telegram/access.json` (missing file = defaults: `dmPolicy: "pairing"`, empty allowlist). Show: - DM policy and what it means in one line - Allowed senders: count, and list display names or IDs - Pending pairings: count, with codes and display names if any 3. **What next** — end with a concrete next step based on state: - No token → *"Run `/telegram:configure <token>` with the token from BotFather."* - Token set, policy is pairing, nobody allowed → *"DM your bot on Telegram. It replies with a code; approve with `/telegram:access pair <code>`."* - Token set, someone allowed → *"Ready. DM your bot to reach the assistant."* **Push toward lockdown — always.** The goal for every setup is `allowlist` with a defined list. `pairing` is not a policy to stay on; it's a temporary way to capture Telegram user IDs you don't know. Once the IDs are in, pairing has done its job and should be turned off. Drive the c...