OpenClaw in Slack, Discord and Teams: Group Rules Without the Noise

Personal channels are forgiving. If your assistant misfires in a WhatsApp thread with yourself, nobody cares. Workplace channels are not forgiving. A bot that replies to every message in #engineering, or answers a question using context from a private DM, is a problem you have to apologise for.

The technical setup for Slack, Discord and Teams is straightforward. The part worth getting right is the behaviour: when the agent speaks, what it can see, and whose conversation it’s holding in memory. This page covers both, with the second weighted more heavily — because that’s where the actual difficulty lives.

The Structural Difference

Personal channels are essentially one-to-one. Workplace channels are one-to-many, and that changes three things at once:

Many people can address the agent. Every one of them is an input source, and not all inputs are trustworthy — including well-meaning colleagues who paste a log file containing text they didn’t read.

Volume is much higher. A default that’s fine in a family group chat is financially and socially unacceptable in a busy team channel.

Context bleeds more easily. Threads, channels, DMs and shared history all exist simultaneously, and the wrong session configuration lets them mix.

So the working order for workplace channels is: restrict first, connect second, widen third. Get the tool policy and session scoping right before the bot is reachable by anyone but you.

Slack

Creating the app

Slack requires a Slack app rather than a simple bot token. At api.slack.com/apps, create a new app for your workspace, then:

Enable Socket Mode. This lets OpenClaw connect outbound over a WebSocket instead of you exposing a public HTTP endpoint for Slack to call. For a self-hosted Gateway on loopback, this is the difference between “works” and “requires a tunnel and a reverse proxy.”
Add bot scopes. At minimum you need to read messages in channels the bot is in, post messages, and see basic user info. Slack’s scope list is granular — grant narrowly and add more when something actually fails, rather than ticking everything.
Subscribe to events. Message events for channels and DMs.
Install to the workspace. You’ll get a bot token (xoxb-…) and, with Socket Mode, an app token (xapp-…).

Configuration

{
  channels: {
    slack: {
      botToken: "xoxb-...",
      appToken: "xapp-...",
      dmPolicy: "pairing",
      allowFrom: ["U123ABC", "U456DEF"],
      channels: {
        C123ABC: { enabled: true, requireMention: true }
      }
    }
  }
}

Slack identifiers are opaque IDs, not display names. Users are U…, channels are C…. In allowlists Slack peers take the form user:U12345. You can find IDs in a member’s profile menu or, more easily, in the Control UI when a message arrives.

Note the shape of channels: an explicit allowlist of channel IDs. The bot works in the rooms you name and nowhere else. That’s the right default for a workspace — it means adding the bot to a channel isn’t sufficient to make it active there. Someone has to change config too.

Threads

Slack conversation lives in threads, and OpenClaw handles this:

{
  session: {
    threadBindings: { enabled: true }
  }
}

With thread bindings on, each thread carries its own continuous context instead of merging into one channel-wide conversation. This matters a lot in practice — two parallel threads in #support are two different problems, and an agent that conflates them gives confidently wrong answers.

Discord

Creating the bot

At the Discord Developer Portal: create an application, add a bot user, copy the token.

The step people miss: Privileged Gateway Intents. Under the Bot settings, enable Message Content Intent. Without it your bot receives message events with empty content and appears completely broken — it connects fine, sees messages arrive, and has nothing to read. This is the single most common Discord setup failure and it produces no useful error message.

Then generate an OAuth2 invite URL with the bot scope and the permissions you need (Read Messages, Send Messages, Read Message History), and use it to add the bot to your server.

Configuration

{
  channels: {
    discord: {
      token: "your-bot-token",
      dmPolicy: "pairing",
      allowFrom: ["123456789012345678"],
      guilds: {
        "987654321098765432": {
          requireMention: false,
          channels: {
            general: { enabled: true },
            help:    { requireMention: true }
          }
        }
      }
    }
  }
}

Discord nests config by guild (server), then channel. That gives you genuinely fine-grained control: a dedicated #ask-the-bot channel where no mention is needed, and everywhere else requiring one.

Discord user IDs are long numeric snowflakes. Enable Developer Mode in Discord’s settings to get “Copy ID” on right-click.

The Discord-specific risk

Discord servers are frequently semi-public, with members you’ve never met and invite links that spread. If your agent is active in a public server, every member is an input source into a model holding your tool permissions.

If you run OpenClaw in a public or semi-public Discord, do it with a dedicated, deliberately crippled agent:

{
  agents: {
    entries: {
      discord_public: {
        tools: { allow: ["read", "web_search"], deny: ["exec", "write", "browser"] },
        sandbox: { mode: "all", workspaceAccess: "ro" }
      }
    }
  }
}

No exec, no write, read-only workspace. Injected instructions from a stranger then have nowhere to land — the worst case is a wrong answer rather than a command running on your machine.

Microsoft Teams

Teams is the most involved of the three, because it’s the most enterprise-shaped. Expect to work through Azure app registration, a bot resource, and — depending on your tenant — an approval from someone in IT.

Two things to know before you start:

You may not be allowed to. Many organisations restrict which apps can be added to a tenant. Check policy before you spend an afternoon on registration.

Compliance is a real consideration, not a formality. A Teams bot with a self-hosted agent means workplace conversations — potentially covering customers, staff, or regulated material — flow to a model provider through infrastructure your IT department hasn’t reviewed. In a regulated industry that’s a conversation to have first, in writing.

If you’re evaluating OpenClaw for a team rather than yourself, note the project’s own position: the documented trust model is one trusted operator per Gateway, a personal-assistant design. It’s explicitly not built for hostile multi-tenant use. You can absolutely run it in a team context, but you’re operating outside the shape it was designed for, and the isolation work is yours to do.

Mention Gating: The Setting That Decides Whether People Hate Your Bot

requireMention defaults to on, and in workplace channels it should stay on almost everywhere.

The failure mode without it isn’t subtle. A bot in a channel with fifty messages an hour responds fifty times an hour. Every response is a model invocation you pay for and an interruption your colleagues didn’t ask for. It takes about a day for someone to mute the channel and roughly a week for someone to ask you to remove it.

But strict literal mentions make conversation robotic — nobody wants to type @assistant on every line of a back-and-forth. That’s what implicit mentions solve:

{
  channels: {
    defaults: {
      implicitMentions: {
        replyToBot: true,
        quotedBot: true,
        threadParticipation: true
      }
    }
  }
}

Now the agent treats a reply to its message, a quote of its message, or continued participation in a thread it’s part of as being addressed. You mention it once to start, then talk normally. It stays quiet in the surrounding channel.

This combination — requireMention: true plus generous implicitMentions — is the setting that makes a workplace bot feel natural instead of either deaf or deafening.

The precedence order

Settings resolve from general to specific, most specific winning:

channels.defaults
      │
      ▼
channels.<platform>            e.g. channels.slack
      │
      ▼
per-guild / per-channel        e.g. guilds.<id> / channels.C123
      │
      ▼
per-group override             e.g. groups."-1001234567890"

When behaviour doesn’t match what you set, you almost always set it at the wrong level and something more specific is overriding you.

Multi-User Safety: The Non-Negotiables

If more than one person can reach your agent, three settings stop being preferences.

1. Isolate sessions.

{
  session: { dmScope: "per-channel-peer" }
}

Every sender gets their own context. Without this, one colleague’s conversation can be in the window while the agent answers another. Nothing errors; it just quietly knows things it shouldn’t.

2. Lower the capability floor.

{
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs"],
    exec: { security: "deny", ask: "always" }
  }
}

The agent your colleagues talk to does not need shell access. If you also want a powerful agent for yourself, make it a separate agent reachable only from your own DMs — don’t grant the shared one exec and hope.

3. Say the bot is there.

Not a technical control, but it belongs on this list. People are entitled to know an AI is reading a channel they speak freely in. Depending on jurisdiction and what’s discussed, it may also be a legal requirement rather than a courtesy.

In practice the announcement matters less than the channel topic. People forget a message from three months ago; they see the topic every time they scroll up. Something short does the job — what it is, who runs it, and how to reach that person:

🤖 This channel includes an AI assistant (OpenClaw, self-hosted by @yourname). It reads messages in this channel and responds when mentioned. Questions or concerns → DM me.

The “who runs it” part is the bit people actually want. An unattributed bot in a work channel makes people uneasy in a way a clearly-owned one doesn’t.

Cost Control in Busy Channels

Workplace channels are where costs get away from people, because the traffic is not something you control.

Practical measures:

Keep requireMention on. This is by far the biggest lever — it takes the agent from “responds to everything” to “responds when asked.”
Allowlist channels explicitly. Don’t let adding the bot to a room be sufficient to activate it.
Route cheap contexts to a cheaper model. Per-channel model overrides (channels.modelByChannel) let a high-volume support channel use a smaller model while your own DMs get the good one.
Watch the first week. The Control UI shows sessions and tool calls live. Actual usage almost never matches what you predicted.

One caution on cheaper models: for tool-enabled agents, or agents reading untrusted content, the documentation is explicit that prompt-injection risk with older or smaller models is often too high. Save money on the read-only agent in the busy channel, not on the one with your shell.

A Workplace-Safe Starting Configuration

{
  session: {
    dmScope: "per-channel-peer",
    threadBindings: { enabled: true }
  },

  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs"],
    exec: { security: "deny", ask: "always" }
  },

  channels: {
    defaults: {
      groupPolicy: "allowlist",
      implicitMentions: {
        replyToBot: true,
        quotedBot: true,
        threadParticipation: true
      }
    },

    slack: {
      botToken: "xoxb-REPLACE",
      appToken: "xapp-REPLACE",
      dmPolicy: "pairing",
      allowFrom: ["user:UYOURID"],
      channels: {
        C_YOUR_TEST_CHANNEL: { enabled: true, requireMention: true }
      }
    }
  }
}

Start in one low-traffic test channel with yourself as the only allowed DM sender. Live with it for a week. Then widen — one channel at a time, watching what the agent actually does with the extra reach.

Things That Go Wrong

Discord bot connects but never responds. Message Content Intent is disabled. Enable it in the Developer Portal. This accounts for most Discord failures.

Slack bot is silent in a channel it’s been added to. Being in a channel isn’t enough — the channel ID must be in channels.slack.channels and enabled.

“It answered in the channel with something from my DM.” Session scoping. Set dmScope: "per-channel-peer" today.

The bot replies to its own messages, or to another bot. Loop risk. Most channels guard against this, but if you’ve loosened mention rules in a room containing other bots, tighten them back.

Threads lose context between messages. session.threadBindings.enabled is off.

It responds in some channels but not others, and you can’t see why. Precedence. Walk the chain from channels.defaults down to the per-channel entry and find the most specific setting.

Where to Go Next

Pairing and Allowlists goes deeper on access control — the mechanics of who gets in, and how to give someone partial access rather than all-or-nothing.

If the multi-user warnings on this page raised questions rather than settling them, read The OpenClaw Threat Model next. Workplace channels are the context where the gap between “works” and “safe” is widest.

Written by NPBlue AI Team — AI / Platform Engineers who self-hosts agent infrastructure and writes from real setup, breakage, and hardening work.

Reviewed for technical accuracy. Spot an error? Let us know.