Channels, Day 5 of the Free Comprehensive OpenClaw Course

Which OpenClaw channel should I set up first?

OpenClaw channels are how the agent shows up in your life. The runtime is the brain, the channel is the body. The right first channel depends on where you actually live. If you check Telegram every hour, set up Telegram first. If you live in iMessage, set up iMessage first. The point is to put the agent somewhere you will actually see it.

The honest order I recommend for most people:

1. Telegram. Easiest to wire (three minutes), works on every OS, free, group chats are trivial.
2. WebChat. Built-in, no setup, useful for testing without leaving your dev machine.
3. WhatsApp or iMessage. Set up the one your daily life is on. WhatsApp needs Meta's Business API setup which is fiddly. iMessage requires a Mac running 24/7.
4. Slack or Discord. Set these up if you want the agent in a team or community.

How do I connect OpenClaw to Telegram?

Telegram is the canonical first openclaw channel. The full walkthrough:

1. Open Telegram and message @BotFather.
2. Send /newbot. Pick a name (anything) and a username (must end in "bot"). BotFather replies with an HTTP API token.
3. Copy the token into your agent's .env: TELEGRAM_BOT_TOKEN=....
4. Restart the agent. The runtime detects the token and opens the Telegram connection.
5. In Telegram, search for the bot's username, open the chat, send "hi".

The agent should reply in seconds. If it does not, check the runtime logs, the most common failure is the token has whitespace at the start or end from the paste, or the agent does not have allowlist permission for your Telegram username (see the next section).

Per-channel setup gotchas, the full matrix

Telegram, the easy one. The only real gotcha beyond the token whitespace issue is that Telegram bots cannot initiate a conversation, the user must message the bot first. Your morning briefing pattern works because the user opened the chat at install time, the bot now has a chat ID it can post to. New users have to send the bot a message before the bot can ever reach them.

WhatsApp Business API. The hardest channel to set up. You need a Meta Business account, a verified phone number not in personal use elsewhere, a WhatsApp Business app or BSP partner, and approval that can take days. The cost shape is also different: WhatsApp charges per conversation in 24-hour windows, currently $0.005 to $0.05 depending on country and category. For a personal agent this is fine. For a high-volume customer service bot, the math gets real. Twilio's Sandbox is the fastest path to test without the full Business API approval flow.

Discord, you create an application at discord.com/developers, generate a bot token, and crucially enable the right intents in the bot settings. Without "Message Content Intent" turned on, the bot sees only its own mentions and cannot read full message text. This is the number one Discord setup failure, the bot connects fine but never seems to "hear" anything.

iMessage, the runtime drives the macOS Messages app via AppleScript. You need a Mac running 24/7, the user account signed into iMessage, the script's Accessibility permission granted in System Settings, and Full Disk Access for Messages. The agent posts by inserting AppleScript that types into the active conversation. It works, but it is genuinely fragile. macOS updates can break it. Use this channel only if iMessage is where you live.

Slack, the most production-friendly. You create a Slack app, set the OAuth scopes (chat:write, channels:history, im:history, app_mentions:read at minimum), install to your workspace, and copy the Bot User OAuth Token into the .env. Slack's threading model maps cleanly to OpenClaw's conversation model. Most production team deployments live on Slack.

Can one OpenClaw agent run across multiple channels at once?

Yes. One agent can be on Telegram, WhatsApp, Discord, iMessage, Slack, and WebChat at the same time, and the conversation history is shared (or separated, depending on how you configure the channel bindings) across all of them. You can start a thread in WhatsApp, switch to Telegram, and the agent picks up where you left off.

The catch is access control. If you put your agent on six channels, you have six attack surfaces. Always set an allowlist of usernames or numbers that are allowed to talk to the agent, never run an open public-channel agent. The allowlist lives in AGENTS.md or a per-channel config block. The exact syntax varies by version, check the current docs.

If you want to run a public-facing customer-support style agent, that is a different deployment shape. Day 15, openclaw multi-agent covers the gateway pattern for routing public traffic to a sandboxed sub-agent.

A note on formatting differences

One gotcha that bites people the first time: every channel renders markdown differently. Telegram supports a small subset (bold, italic, code), WhatsApp supports almost none, iMessage shows raw markdown if you send it asterisks, Discord supports a different subset than Telegram. The runtime handles the per-channel rendering automatically if you write the agent's responses in plain text or use the runtime's structured-message helpers.

If you write a SOUL.md that says "always reply in markdown headings", expect Telegram to look fine and iMessage to look like a syntax dump. Either keep the agent's responses plain, or use channel-aware rendering. The latter is in the docs.

Example CHANNELS.md config

The minimum-viable CHANNELS.md for a multi-channel personal agent:

channels:
  telegram:
    enabled: true
    allowlist:
      - "@your_telegram_username"
    rendering: telegram_markdown_v2

  slack:
    enabled: true
    workspace: yourcompany.slack.com
    allowlist_channels:
      - "#agent-private"
    allowlist_users:
      - "U0123456789"
    rendering: slack_blocks

  webchat:
    enabled: true
    bind: "127.0.0.1:3000"
    auth: bearer_token

shared_history: true

The shared_history: true line is the magic that makes the agent feel like one entity across channels. Set it false if you want strict channel isolation, useful if you want a "work" Slack persona and a "personal" Telegram persona to feel like genuinely different conversations.

Common channel security pitfalls

Three real failure modes I have seen on client deployments. Public Telegram bot, no allowlist. Random strangers find the bot through Telegram's search, message it, and the agent dutifully responds. The agent's API spend doubles overnight. Fix: always set an allowlist before going live, even for "private" bots, Telegram's discovery is more aggressive than people expect.

The second, Slack scopes too broad. A bot with users:read.email can read every email address in the workspace. A bot with files:read can read every uploaded file. Grant only the scopes you need. The OAuth dialog shows the user exactly what they are granting, do not make them click through scary scopes.

The third, WhatsApp business cost runaway. A loop in the agent's heartbeat that posts to WhatsApp every minute can rack up real money quickly, given the per-conversation pricing. Always wire the spending caps from openclaw cost optimization when you have WhatsApp connected. Channel cost is real cost, not just API cost.

WebChat, the built-in fallback channel

Every OpenClaw install ships with WebChat enabled by default. It is the simplest channel, no setup, no tokens, just the runtime hosting a small web UI on the local port (3000 by default). Three reasons to keep it around even after you have wired Telegram or Slack.

First, development testing. When you are editing SOUL.md or AGENTS.md and want to see the result fast, the WebChat surface gives you the agent's reply with no channel-formatting noise. You see what the model actually returned, before any markdown rendering munges it.

Second, production embedding. If you want the agent on your own site, WebChat is the path. Bind the runtime to a public port, put nginx in front for TLS, drop a small JS embed on your page. The agent now lives on your site as a chat widget, with the same SOUL and MEMORY as the version you talk to on Telegram.

Third, fallback for broken channels. When Telegram has an outage, when WhatsApp's Business API rate-limits you, when Slack is down, WebChat keeps working. It is the channel of last resort. Always have it enabled, even if you never use it day to day.

Channel precedence and routing rules

If the agent is on multiple channels and a single user can be reached on more than one, which channel does the agent use to reach out? The runtime's default is "the channel the conversation last happened on", which is usually correct, the user is paying attention to whichever app they last messaged from. Override this in CHANNELS.md with explicit routing rules: "Morning briefing always goes to Telegram regardless of last channel", "System alerts always go to Slack #ops", "End of day wrap goes to whichever channel had the most messages today".

The pattern matters because users have channel preferences that vary by intent. Personal agent stuff lives on Telegram, work alerts live on Slack. The agent should respect those boundaries. Hardcoding the routing per intent in CHANNELS.md takes 10 minutes and the agent feels much more polished as a result.

How this connects to your full agent

Channels are where the agent stops being a curiosity and starts being a tool you use. The next four lessons make the agent worth talking to in the first place. Openclaw heartbeat.md on day 6 turns the agent from reactive chatbot to proactive system, sending you the morning briefing on Telegram or Slack without you asking. Openclaw soul.md on day 7 makes the agent's voice on those channels actually feel like a person worth listening to.

If you only set up two channels, do Telegram for personal use and Slack for team use. They cover 90 percent of the practical cases and have the cleanest setup-to-value ratio. Add WhatsApp or iMessage only when you have a reason, the operational overhead is real.