Cross channel communication | Friends of the Crustacean 🦞🤝 | Page 1

tidal mantle May 13, 2026, 7:15 PM

#

Is there a way to comunicate betwean channels. ( telegram->whatsapp->slack ) I tried sending instructions from Telegram channel to slack bot to send DM-s to some of the members and it was constantly refusing.

molten raptorBOT May 13, 2026, 7:15 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

candid berryBOT May 13, 2026, 7:16 PM

#

Yes — but there are two different things that are easy to mix up:

Normal replies route back to the same channel the message came from. If you message from Telegram, OpenClaw’s default reply goes back to Telegram. The model doesn’t “become the Slack bot” automatically. Docs: https://docs.openclaw.ai/channels/channel-routing
Cross-channel sending is possible through the message tool, if that tool is allowed and the destination channel is configured. For Slack DMs the target shape is usually user:U..., and the Slack app needs scopes like chat:write, im:write, users:read, etc. Docs: https://docs.openclaw.ai/cli/message and https://docs.openclaw.ai/channels/slack

So a Telegram instruction like “send this Slack DM to user:U123…” can work, but it may refuse if:

the agent does not have message / group:messaging in its tool allowlist
Slack is configured for inbound chat but the bot token/scopes don’t permit DMs
the request looks like unsolicited outreach/spam or sending messages to other people without clear approval
the target is a name instead of a stable Slack user ID and directory lookup can’t resolve it

I’d set this up as a narrow, explicit workflow: allow the message tool, use Slack user IDs, and phrase the request as a one-off approved send, e.g. “Using the Slack message tool, send exactly: … to Slack user:U123.”

If you want help debugging the actual refusal, paste:

openclaw --version
the exact refusal text

#

whether your agent’s tools include group:messaging or message
whether the Slack app has chat:write + im:write

tidal mantle May 13, 2026, 7:27 PM

#

is there a way to set this up. Can you explain step by step how to implement this

candid berryBOT May 13, 2026, 7:28 PM

#

Yep. The clean setup is: one OpenClaw Gateway with Telegram/WhatsApp/Slack enabled, then give the agent permission to use the outbound message tool. Don’t think of it as Telegram talking to the Slack bot directly — Telegram talks to OpenClaw, and OpenClaw sends to Slack.

Step-by-step:

Check version first

openclaw --version
openclaw status --all

If you’re on an older/beta build, weird channel/tool behavior can be version-specific.

Configure the inbound channel you want to command from

Example Telegram:

#

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "allowlist",
      allowFrom: ["YOUR_NUMERIC_TELEGRAM_USER_ID"]
    }
  }
}

Telegram allowFrom must be the numeric Telegram user ID, not @username.

Docs: https://docs.openclaw.ai/channels/telegram

#

Configure Slack with DM-capable scopes

Use the Slack manifest from the docs. For sending DMs, make sure the Slack app has at least the relevant bot scopes like:

chat:write
im:write
im:read
users:read

The docs manifest includes the normal full set.

Config shape:

#

{
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: "xapp-...",
      botToken: "xoxb-..."
    }
  }
}

Docs: https://docs.openclaw.ai/channels/slack

Allow the agent to use messaging tools

#

If your config uses tool allowlists, add group:messaging or message.

Example:

{
  tools: {
    allow: ["group:messaging"]
  }
}

If you already have a bigger allowlist, add it there instead of replacing everything. group:messaging is the group that contains the message tool.

Docs: https://docs.openclaw.ai/gateway/configuration-reference#tools

Restart the Gateway

#

openclaw gateway restart

Then verify:

openclaw status --deep

Test Slack sending directly before involving the agent

Use a real Slack user ID, usually like U123ABC...:

openclaw message send \

#

  --channel slack \
  --target user:U123ABC456 \
  --message "Test from OpenClaw"

If this fails, the issue is Slack config/scopes/target ID, not the model.

Docs: https://docs.openclaw.ai/cli/message

Then ask from Telegram/WhatsApp with a very explicit instruction

Example:

Send a Slack DM using the message tool to user:U123ABC456. Send exactly: Hey, quick reminder about the meeting at 3.

That should route: Telegram → OpenClaw agent → Slack DM.

#

Important: if you ask it to mass-DM people, send vague outreach, or message members without clear consent, the model may refuse for safety/spam reasons. Best pattern is a narrow allowlisted workflow: exact recipients, exact message text, and preferably one-off human-approved sends.

For cross-channel routing behavior generally: https://docs.openclaw.ai/channels/channel-routing

tidal mantle May 13, 2026, 7:33 PM

#

Slack │ ON │ OK │ tokens ok (bot config, app config) (bot xoxb…YYV5 · len 59, app xapp…e43a · │
│ │ │ │ len 98) · accounts 1/1 │
│ Telegram │ ON │ OK │ token config×5 (8635…jj2I · len 46) · accounts 5/5

candid berryBOT May 13, 2026, 7:33 PM

#

Nice, that status means the channel tokens are basically healthy. So if it’s still refusing, I’d look at these next:

Check whether the agent is allowed to use message

Run:

openclaw config get tools

If you see a restrictive allowlist, add messaging:

{
  tools: {
    allow: ["group:messaging"]

#

}
}

If you already have entries there, don’t replace them — add group:messaging alongside the existing ones.

Test Slack outbound directly

This bypasses the model, so it tells us whether Slack DM sending itself works:

openclaw message send \
  --channel slack \
  --target user:U_SLACK_USER_ID \
  --message "Test from OpenClaw"

#

If that fails, it’s Slack scopes/target/user ID. If it succeeds, the remaining issue is agent/tool policy or the wording/safety refusal.

Be explicit from Telegram

Use Slack’s stable user ID, not a display name:

Send a Slack DM using the message tool to user:U_SLACK_USER_ID. Send exactly: Hello, this is a test from Telegram via OpenClaw.

Because you have Telegram accounts 5/5

If commands come from a specific Telegram account, make sure that account is routed to the same agent that has the message tool enabled. Multi-account setups can accidentally route one Telegram account to an agent/profile without messaging tools.

If you paste the output of:

openclaw config get tools

#

openclaw config get bindings

redacting tokens if any appear, I can help spot the missing piece.

tidal mantle May 13, 2026, 7:33 PM

#

{
"profile": "messaging",
"loopDetection": {
"enabled": true
},
"message": {
"crossContext": {
"allowWithinProvider": true,
"allowAcrossProviders": true,
"marker": {
"enabled": true,
"prefix": "[from {channel}] "
}
}
}
}

candid berryBOT May 13, 2026, 7:34 PM

#

That config looks like the right shape for cross-provider sending:

tools: {
  profile: "messaging",
  message: {
    crossContext: {
      allowAcrossProviders: true,
      marker: { enabled: true, prefix: "[from {channel}] " }
    }
  }
}

So next I’d implement/debug it like this:

Restart after that config change

#

openclaw gateway restart

Verify Slack can send a DM without the model involved

openclaw message send \
  --channel slack \
  --target user:U_SLACK_USER_ID \
  --message "Test from OpenClaw"

If this fails, fix Slack first. Common causes: wrong user ID, missing im:write, app not reinstalled after scopes changed.

Verify Telegram → Slack using an exact instruction

#

From Telegram, send something very explicit:

Use the message tool to send a Slack DM to user:U_SLACK_USER_ID.
Send exactly: Hello, this is a Telegram → Slack test through OpenClaw.

If you want Telegram → WhatsApp → Slack as separate sends

Ask for both sends explicitly:

Use the message tool twice:
1. Send this WhatsApp message to +15551234567: "Test from Telegram via OpenClaw"
2. Send this Slack DM to user:U_SLACK_USER_ID: "Test from Telegram via OpenClaw"

#

Target formats matter:

Slack DM: user:U...
Slack channel: channel:C...
WhatsApp DM: +15551234567
Telegram chat: numeric chat id or @username

Important: your config permits cross-provider tool use, but it does not create an automatic bridge by itself

Meaning: a Telegram message won’t automatically forward to Slack unless the agent is instructed to do it, or you build a standing workflow around it.

For a reliable “bridge command”, add a standing instruction in your agent/workspace like:

When I ask to "forward to Slack", use the message tool with channel=slack. Require an explicit Slack `user:...` or `channel:...` target and exact message text. Do not guess recipients.

If it still refuses

#

Paste the exact refusal text. There are two different refusal classes:

“cross-context / cross-provider denied” → config not loaded or wrong agent/account route.
safety refusal about DMing members → ask with exact recipient IDs + exact text, avoid bulk/unsolicited outreach wording.

Docs for this exact error: https://docs.openclaw.ai/help/faq#how-do-i-send-a-discord-message-from-telegram-cross-context-messaging-denied

tidal mantle May 13, 2026, 7:35 PM

#

i want to say like this on telegram hey agent send a messag to "Some person" on slack. Just say Hello from Openclaw.
is That possible

candid berryBOT May 13, 2026, 7:35 PM

#

Yes — possible, with one caveat: Slack display names are messy. The reliable version is using the Slack user ID (user:U...).

Best setup:

First find the Slack user ID for “Some person”. In Slack it usually looks like U123ABC456.
Then from Telegram say:

Hey agent, send a Slack DM to user:U123ABC456. Say exactly: Hello from OpenClaw.

That should work if:

Slack outbound test works
tools.profile: "messaging" is active for the Telegram-routed agent
tools.message.crossContext.allowAcrossProviders: true is loaded

If you want to say the human-friendly version:

#

Hey agent, send a message to Some Person on Slack. Just say: Hello from OpenClaw.

…it may work only if OpenClaw/Slack directory lookup can resolve that person unambiguously. If there are duplicate names, nicknames, stale cache, or the Slack app lacks user lookup access, the agent should ask you for the exact user:U... ID instead of guessing.

My recommendation: create a small contact note in your workspace/agent instructions, like:

Slack contacts:
- Some Person = user:U123ABC456

Then your natural Telegram command can be short, and the agent has a stable ID to use. 🦞

tidal mantle May 13, 2026, 10:28 PM

#

i am encountering the same issue on the cross channel messaging. When i try to send a message from telegram to whatsapp i get this error
18:26:16-04:00 error [tools] message failed: Error: No active WhatsApp Web listener (account: 8635213747). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account 8635213747. raw_params={"action":"send","channel":"whatsapp","target":"+38761877000","message":"hello"}
Log tail truncated (increase --max-bytes).

candid berryBOT May 13, 2026, 10:28 PM

#

This one is not a cross-channel permission problem anymore — the message tool got as far as WhatsApp, then WhatsApp said: “I don’t have an active linked WhatsApp Web session for account 8635213747.”

That account id looks suspiciously like your Telegram account id being carried into the WhatsApp send. WhatsApp needs its own linked account/listener.

Do this:

Check what WhatsApp accounts OpenClaw knows about:

openclaw config get channels.whatsapp
openclaw status --deep

If you actually want WhatsApp account 8635213747, link it:

#

openclaw channels login --channel whatsapp --account 8635213747
openclaw gateway restart

More likely: set WhatsApp to the account you actually linked, usually default or whatever appears in your WhatsApp config:

{
  channels: {
    whatsapp: {
      defaultAccount: "default"
    }
  }
}

#

Then restart:

openclaw gateway restart

Test WhatsApp outbound directly, bypassing Telegram/the model:

openclaw message send \
  --channel whatsapp \
  --account default \
  --target +REDACTED_NUMBER \
  --message "hello"

If your WhatsApp account is not default, replace it with the real account id.

#

From Telegram, make the agent specify the WhatsApp account explicitly:

Use the message tool to send a WhatsApp message with accountId "default" to +REDACTED_NUMBER. Say exactly: hello

If that works, the fix is to make your standing instruction include: “When sending WhatsApp messages from Telegram, use WhatsApp accountId default.”

Also please run/paste this if it still fails:

openclaw --version
openclaw config get channels.whatsapp
openclaw message send --channel whatsapp --account default --target +REDACTED_NUMBER --message "hello" --verbose

Redact phone numbers/tokens before posting. 🦞

tidal mantle May 13, 2026, 10:30 PM

#

OpenClaw 2026.5.7 (eeef486)
{
"accounts": {
"default": {
"enabled": true
}
},
"enabled": true,
"dmPolicy": "allowlist",
"allowFrom": [
"+38761877000",
"+38762409924"
],
"blockStreaming": true,
"groupPolicy": "allowlist",
"debounceMs": 0,
"mediaMaxMb": 50
}

candid berryBOT May 13, 2026, 10:30 PM

#

Thanks — that confirms WhatsApp is configured as account default, but the failed tool call tried account 8635213747.

So the problem is account selection, not the phone number allowlist.

Try this direct test first:

openclaw message send \
  --channel whatsapp \
  --account default \
  --target +38761877000 \
  --message "hello from OpenClaw"

If that works, then from Telegram say:

#

Use the message tool to send a WhatsApp message using accountId "default" to +38761877000. Send exactly: hello from OpenClaw

Why this happened: the inbound Telegram account id is 8635213747, and it looks like the model/tool call reused that as the outbound WhatsApp account. But your WhatsApp listener is only registered as default, so WhatsApp correctly says there’s no active listener for 8635213747.

For a durable fix, add a standing instruction to the agent, for example in AGENTS.md or your workspace instructions:

When sending WhatsApp messages via the message tool, always use accountId "default" unless the user explicitly provides a different WhatsApp account id.

If the direct test with --account default fails too, then the WhatsApp Web listener isn’t actually active yet — run:

openclaw channels login --channel whatsapp --account default

#

openclaw gateway restart
openclaw status --deep

But based on your config, I’d bet the explicit accountId: "default" fixes the cross-channel send.

tidal mantle May 13, 2026, 10:31 PM

#

◇ Config warnings ─────────────────────────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.whatsapp: plugin whatsapp: blocked plugin candidate: suspicious │
│ ownership (/data/.openclaw/npm/node_modules/@openclaw/whatsapp, uid=1000, expected │
│ uid=0 or root) │
│ - plugins.entries.whatsapp: plugin present but blocked: whatsapp (see preceding plugin │
│ warning; source: /data/.openclaw/npm/node_modules/@openclaw/whatsapp; fix the blocked │
│ plugin path instead of removing config) │
│ - plugins.allow: plugin present but blocked: whatsapp (see preceding plugin warning; │
│ source: /data/.openclaw/npm/node_modules/@openclaw/whatsapp; fix the blocked plugin │
│ path instead of removing config) │
│ │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
Error: Channel is unavailable: whatsapp
root@bdf3dd688352:~#

candid berryBOT May 13, 2026, 10:32 PM

#

Yep — this explains the new failure.

WhatsApp is configured, but the WhatsApp plugin is being blocked before it loads:

suspicious ownership (.../@openclaw/whatsapp, uid=1000, expected uid=0 or root)
Error: Channel is unavailable: whatsapp

You’re running the CLI as root inside the container, but the plugin files under /data/.openclaw/npm/node_modules/@openclaw/whatsapp are owned by UID 1000. OpenClaw blocks that as a plugin safety check, so the WhatsApp channel never becomes available.

Fix one of these two ways:

Option A — if the container/gateway runs as root

#

chown -R root:root /data/.openclaw/npm/node_modules/@openclaw/whatsapp
openclaw gateway restart

Then verify:

openclaw status --deep
openclaw message send --channel whatsapp --account default --target +38761877000 --message "hello"

Option B — better long-term if your /data volume is owned by UID 1000

Run the OpenClaw container/process as UID 1000 instead of root, so the current process UID matches the plugin ownership. In Docker setups this usually means setting the container user / OpenClaw docker.user to the same UID:GID as the mounted /data volume.

Docs mention the same ownership principle here: https://docs.openclaw.ai/install/docker#troubleshooting

#Cross channel communication