OpenClaw’s Telegram channel is usually shown as a personal chatbot. I used it for something narrower: the place where AI coding agents stop and ask me before they continue.

In my MVP studio setup, five OpenClaw agents and a deterministic Python orchestrator ran on a single VPS. Only one of them, the PM agent, talked to me on Telegram. It sent the plan, waited for my go, and escalated what it could not decide. Most of the time I never opened the dashboard.

This article covers the setup steps that matter, then the approval design that made a phone a safe control surface for agents that run shell commands and push code.

01

Connect OpenClaw to Telegram in five steps

The official setup is short. At the time of writing (October 2026), OpenClaw’s Telegram documentation describes this sequence:

  • Create a bot with @BotFather (run /newbot, or use BotFather’s web app) and keep the token it returns.
  • Give OpenClaw the token with openclaw channels add --channel telegram --token <bot-token>, or set channels.telegram.botToken in ~/.openclaw/openclaw.json. Telegram does not use a login command.
  • Check the channel with openclaw channels status --probe. If the gateway is offline, start it with openclaw gateway start.
  • Send your bot any message, then approve that pairing with openclaw pairing list telegram and openclaw pairing approve telegram <CODE>. Pairing codes expire after one hour.
  • For a group, add the bot and allow the group chat ID under channels.telegram.groups. Telegram’s privacy mode hides most group messages from bots until you change it with /setprivacy or make the bot a group admin.

The default direct-message policy is pairing, so someone who finds the bot cannot simply start giving it instructions. Keep it that way. A bot that can trigger agents with shell and GitHub access is an entry point to your server.

02

Give Telegram to one agent, not five

My setup had five specialized coding agents and an orchestrator. Only the PM agent was connected to Telegram. The other agents had no chat surface and were started by the orchestrator from the command line.

That choice kept the phone quiet. I talked to one role that held the plan and the scope, instead of five agents each asking their own questions. When a developer agent needed a product decision, it asked the PM first. Only what the PM could not settle reached me.

The escalation chain was explicit:

  • A developer agent needs a product decision: it asks the PM agent.
  • A developer agent needs something external, such as an API key or a third-party service: it messages me on Telegram and stops until I answer.
  • The reviewer agent is still blocked after three review cycles: the task escalates to me.
  • The PM is unsure about scope: it asks me on Telegram.

No agent tries to solve a problem outside its role. That rule, more than any Telegram setting, is what keeps the message volume low enough to read every message properly.

03

The one approval that pays for itself: the plan

Every project started from a template repository. I wrote a short IDEA.md describing the app, pushed it, and sent the PM one Telegram message asking it to read the idea.

The PM produced an architecture document, a prioritized KANBAN, task specs and API contracts, then sent me the plan on Telegram and waited. Nothing was built until I replied “Go”.

That stop was the most valuable approval in the system. A few minutes reviewing a plan on a phone is cheap. Letting agents build the wrong thing for hours is not. On the first real project, the same stop also let me redirect the frontend agent twice when its UI approach did not match what I wanted.

Read where an approval belongs in an AI workflow. The same rule applies beyond coding agents: approve the action that is expensive to undo, not every intermediate answer.

04

Let a script send the status updates

The orchestrator was a Python loop, not an agent. It polled the KANBAN every 60 seconds, picked the next ready task in dependency order, started the right agent, sent finished work to the reviewer agent, and merged once the reviewer approved.

It also sent Telegram status notifications directly through the Telegram Bot API, including the final “MVP done” message. Routine progress did not need a model to phrase it, and a deterministic sender cannot decide to skip a notification.

That split is the pattern I would keep: the agent asks the questions that need judgment, and the script reports the facts. When something broke, I could read the script and find the cause in minutes instead of guessing why a model chose to skip a task.

Read why the control path should stay deterministic. Task order, retries and state transitions are rules, so a script handles them better than a model.

05

Command approvals are a separate feature

The approvals above were conversational: the PM asked, and I answered in the chat. OpenClaw also documents a stricter mechanism, exec approvals, which asks a named person before an agent runs a command.

According to OpenClaw’s Telegram documentation, exec approvals are configured under channels.telegram.execApprovals, approvers must be numeric Telegram user IDs, prompts go to the approver’s direct messages by default, and an approval expires after 30 minutes by default. Inline approve and deny buttons also need channels.telegram.capabilities.inlineButtons to allow that chat type.

Two details are easy to miss. Being allowed to talk to the bot does not make someone an approver. And posting approval prompts into a group shows the command text to everyone in it, so the documentation advises enabling that only in trusted groups or topics.

My MVP setup relied on scope instead: each GitHub repository had its own deploy key, so an agent could only reach the repositories I had explicitly added. For an agent with access to production data or shared infrastructure, command-level approval is worth the extra taps.

06

What to set up first

If you are connecting OpenClaw agents to Telegram for real work, this is the order I would follow:

  • Keep the pairing direct-message policy and approve only your own account.
  • Connect one coordinating agent to Telegram, not every worker.
  • Write the escalation chain into each agent’s instructions and the project conventions, so an agent knows when to stop and ask.
  • Make the plan review a hard stop before any code is written.
  • Send routine status from a script, and keep the model for questions.
  • Scope credentials per repository, so a wrong approval has a small blast radius.

The whole setup ran on a single VPS for about $6 a month. The architecture, the five agents and what the experiment taught me, including why I paused it, are in the case study.

Read the OpenClaw MVP studio case study. Five AI coding agents, a deterministic Python orchestrator and the Telegram approval flow on one VPS.