Which apps can message an OpenClaw agent: Telegram, WhatsApp, iMessage, Slack, or only the desktop app?

Telegram, WhatsApp, iMessage, and Slack can all message an OpenClaw agent. The desktop app is not the only door. OpenClaw’s channel directory also includes Discord, Signal, Google Chat, Microsoft Teams, Matrix, and a long list of plugins, and the browser Control UI ships a WebChat that is part of the core install. The macOS app and the iPhone app are clients of the same Gateway. They are extra ways to talk to it, not a requirement that you sit at a desktop.

Every one of those paths still assumes one thing: a Gateway process you run yourself. OpenClaw is the self-hosted gateway from the OpenClaw Foundation. Chat apps do not each contain a private copy of the agent. They connect to the Gateway, and the Gateway is what runs the turn, holds the session, and calls the model. If that process is down, the app on your phone can still accept typing. OpenClaw cannot answer.

Is the desktop app a channel?

No. Treat the desktop app as a client, and treat channels as the messaging accounts the Gateway logs into.

The project describes the shape this way. One Gateway process is the bridge. Around it sit the command line, the browser Control UI, the macOS app, iOS and Android nodes, and whatever channel plugins you turned on. WebChat has no separate port. It rides the Gateway WebSocket, which by default listens on 127.0.0.1:18789. You open it with openclaw dashboard after the Gateway is up. That is a real way to send a message, and it does not involve Telegram or Slack at all. It is also not “the product.” It is the local control surface.

The iPhone app has its own Chat screen: text, dictation, a voice note, and a Talk control. That chat is still a session on the Gateway you paired. The phone keeps a small read-only cache of recent transcripts so a cold open can paint the last thread, then it refreshes when the Gateway answers. Cache is not a second brain. If you have never connected a Gateway, the phone app has nothing to drive.

So the honest map is three layers. Channels are Telegram, WhatsApp, iMessage, Slack, and the rest. Operator apps are the Control UI, the macOS app, and the phone chat. The Gateway is the only place the agent actually runs. People who say “OpenClaw is a desktop app” have used one client and missed the product.

Why do the docs tell you to start with Telegram?

Because it is the shortest path from a running Gateway to a message on a phone.

Telegram ships as a bundled plugin. You do not install a separate package first. You need a bot token. The documented command is openclaw channels add --channel telegram --token followed by that token, or openclaw channels add with no flags if you would rather pick from a list. With the default hot reload, a running Gateway picks up the new account. If the Gateway is offline, start it, then check openclaw channels status --probe.

That probe matters more than the moment the command exits. A token saved in config is not the same as a live connection. I use Telegram as the first channel on a new host for the same reason the docs do: the failure modes are boring. Wrong token, Gateway not running, pairing not approved. You are not also debugging a QR login or a Mac permission prompt on day one.

Telegram is a bot, which means the thing your friends message is a bot account, not your personal Telegram login. That is the right default. Your own chats stay yours. The bot is a mailbox you chose to attach. Group behavior is separate from DMs. Discord, LINE, Matrix, Slack, and Telegram can post a one-time room introduction when the bot joins an allowed group. The docs say that introduction turn runs with no tools available, so text sitting in the room history is not handed a shell. Mention rules still exist for ordinary group messages. Connecting Telegram does not mean every group you can see becomes a place the agent acts.

What does WhatsApp add, and what does it store?

WhatsApp is an official plugin, not part of the smallest core install. Onboarding can show the setup flow before the package is installed. The Gateway loads the plugin when the channel is actually active. Setup is a QR pairing, the same shape as linking WhatsApp Web, and the docs warn that it stores more state on disk than Telegram does.

That extra state is the trade. WhatsApp is where a lot of real life already happens, so the agent is sitting in a thread you would have opened anyway. The cost is a login session on the Gateway host, plus whatever message state the plugin keeps. The channel page is explicit that DM pairing and allowlists are there for safety. Default DM policy across channels is pairing: an unknown sender gets a code, and the bot does not process their message until you approve them. I would not flip that to open because a family group felt convenient. The QR link and the allowlist are different locks. The QR link proves the Gateway may speak as that WhatsApp account. The allowlist decides which senders get an agent turn.

If the Gateway host is a closet computer and the phone that shows the QR code is in your hand, do the pairing while you are next to the machine and can see the Control UI. A QR code is a login. Treat the screen the way you would treat a WhatsApp Web prompt, then put the phone down. The ongoing connection belongs to the Gateway after that, which is why this channel is a poor fit for a laptop you close every night. None of these apps answer while the Gateway host is asleep.

Can iMessage work without a Mac signed into Messages?

Not in the setup the docs describe. For the usual deployment, the Gateway and imsg run on the same Mac that is signed into Messages. The Gateway spawns imsg rpc and talks JSON-RPC over standard input and output. There is no separate iMessage daemon and no extra port in that design. If the Gateway lives on a Linux box or a VPS, the documented alternative is to point channels.imessage.cliPath at an SSH wrapper that runs imsg on the Mac. The Mac is still in the path. You moved the Gateway, not the Messages account.

BlueBubbles is not the current path. The docs say that support was removed and that existing channels.bluebubbles config should move to channels.imessage. OpenClaw speaks iMessage through imsg only.

What you can do in that thread depends on how far you take the Mac side. The docs strongly encourage a private API mode for a complete channel: replies, tapbacks, effects, polls, attachment replies, and group actions need imsg launch and a successful private API check. That path is documented separately, including what remains if System Integrity Protection stays on. I am not going to walk through disabling SIP here. Read that page on docs.openclaw.ai and decide whether those native actions are worth the host change. A lot of people only need “text in, text out” on a Mac that is already their Messages machine. That is a smaller setup than the full private API, and it is still iMessage, not a pretend SMS gateway.

There is a practical deployment note worth copying. The docs describe a dedicated macOS user for the bot so the agent’s iMessage identity is not your personal one, and a remote Mac over Tailscale when the Gateway is elsewhere. Both are operator setups. Both still require a real Messages login on Apple hardware. There is no official “iMessage plugin” that runs purely on a Linux VPS with no Mac behind it.

Inbound recovery is one behavior I would want if I used this channel. After a bridge or Gateway restart, the docs say iMessage replays messages missed while it was down and suppresses the stale backlog Apple can flush after a push recovery, with deduping so a message is not dispatched twice. There is no switch to turn that on. It is the documented restart behavior. It does not help while the Mac itself is off.

What are Slack’s actual connection modes?

Slack is an official plugin. The channel index names three runtime modes: Socket Mode, HTTP Request URLs, and relay mode. I am not going to invent a default button or a plan name on top of that. The docs page for Slack is the place that spells out which mode matches a workspace that can accept a socket and which mode needs a public URL.

Two behaviors are specific enough to plan around. Slack multi-person DMs are routed as group chats, so group policy, mention rules, and group sessions apply to those conversations. A message in a huddle of three people is not a private DM just because it feels like one. And Slack is one of the channels that can post a join introduction in the room that was joined, once per room, with a claim that lasts 90 days so a Gateway restart does not spam the channel.

Slack is also the channel people are tempted to set to open, because a workspace already feels like an allowlist. It is not. Anyone who can DM the bot, including a guest account you forgot, is a sender under the DM policy. Pairing is still the default. An allowlist is the tighter choice when you know the member IDs. Open requires the allowlist to include * on purpose. Leave that decision for the access-control page, and do not treat “we use Slack” as the approval.

Which other apps are actually on the list?

The question named four. The channel index is much longer, and the labels matter because they tell you who ships the code.

• Included in core: WebChat, over the Gateway WebSocket.
• Bundled plugins: Telegram, plus A2A for external agents, Reef, and X for mentions and allowlisted public replies.
• Official plugins you install on demand: Discord, Signal, WhatsApp, iMessage, Slack, Google Chat, Microsoft Teams, Matrix, Mattermost, Feishu, LINE, IRC, Nostr, QQ, Twitch, Zalo, Nextcloud Talk, Synology Chat, SMS through Twilio, and others on the same index.
• External plugins, maintained outside the OpenClaw repo: WeChat via the openclaw-weixin plugin, WeCom, Yuanbao, and Zalo ClawBot.

Voice Call is listed beside those as a telephony plugin through Plivo, Telnyx, or Twilio. That is a phone call, not a chat bubble. It is still a Gateway channel in the sense that the Gateway is the thing that answers. It is not a reason to skip the text channels above.

“Supported” does not mean “identical.” Text works across the directory. Media and reactions vary by channel. Group mention rules vary. Some plugins install with openclaw plugins install or during openclaw onboard and openclaw channels add. External plugins are someone else’s release cycle. If a title in a chat group promised a channel that is not on docs.openclaw.ai, I would not trust the promise. The index is the list.

Can several of these be connected at once?

Yes. The docs say channels can run simultaneously, and the Gateway routes per chat. One Gateway, many accounts. Telegram for your pocket, Slack for a workspace, WebChat when you are at the browser. That is the normal shape, not an advanced mode.

What does not come free is session hygiene. By default, direct messages share the agent’s main session so a conversation can continue across devices. That is convenient when you are the only sender. It is the wrong default when more than one person can DM the bot. The config value is session.dmScope. main is the default. per-channel-peer gives each channel and sender an isolated DM context. Set that before you invite a second human, not after two people’s tasks have already been braided into one transcript.

Model choice can also vary by channel, through channels.modelByChannel, but only when the session does not already have a model override. Switching the provider is a different article. The point here is that “the Slack bot” and “the Telegram bot” are not two agents unless you configured them that way. They are two doors into routing rules you set.

What does “can message” fail to promise?

It does not promise that a stranger’s text becomes a tool call. Pairing is the default DM policy. Unknown senders get a code and are ignored until you approve them. Codes expire. Pending requests are capped. Allowlist mode skips the handshake and blocks everyone who is not already listed. Open mode is an explicit opt-in. Disabled mode drops inbound DMs. Those four policies are the real answer to “who can talk to it,” and they apply on top of the fact that the app is supported.

It does not promise the same message actions everywhere. An iMessage tapback is not a Telegram reaction is not a Slack emoji. Read the channel page before you tell the agent to “react.” It does not promise the desktop app can substitute for a channel login. The macOS app can operate the Gateway remotely. It does not log the Gateway into your WhatsApp account by existing. And it does not promise a reply while the host is suspended, no matter how many apps you connected on a good afternoon.

It also does not promise that a bot-to-bot conversation will stop by itself if you point two agents at each other. The docs mention shared loop protection for channels that accept bot-authored inbound messages, specifically so a pair of bots does not reply forever. Turn that over in your head before you put OpenClaw in a room with another bot and walk away. Loop protection is a backstop, not a design.

How do you confirm an app is really attached?

Add the channel, then probe it. openclaw channels status --probe is the check the install docs name. The Control UI is the place you approve a first DM if you are using the default pairing policy. Send one message from the account you expect to be allowed, from the app itself, not from WebChat. WebChat proving the Gateway is up does not prove Telegram is connected.

Then send one message from an account you have not approved, and confirm it does not get an agent reply. That second test is the one people skip. A supported app with an open policy is a public agent wearing a familiar icon. The icon is not the control. The policy is.

If you only remember one line, remember this one. Telegram, WhatsApp, iMessage, and Slack are all real OpenClaw channels, and so are many other apps on the official index. The desktop app is a client. The Gateway is the product. Connect the app you already check. Keep pairing on until you have a reason to write down an allowlist.