/telegram:configure, Telegram Channel Setup

Writes the bot token to <state-dir>/.env and orients the user on access policy. The server reads both files at boot.

Resolve the state directory first (it may be overridden for multi-bot or per-project setups):

echo "${TELEGRAM_STATE_DIR:-${CLAUDE_CONFIG_DIR:-$HOME/.claude}/channels/telegram}"

Use the printed path everywhere below in place of <state-dir>. The default is ~/.claude/channels/telegram.

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 <state-dir>/.env for TELEGRAM_BOT_TOKEN. Show set/not-set; if set, show first 10 chars masked (123456789:...).

2. Access, read <state-dir>/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 conversation this way: