Setting Up OpenClaw AI Agents in Slack - A Complete Walkthrough

Slack is where most Australian knowledge workers actually spend their day. Not in a CRM, not in a project management tool - in Slack, typing messages and reacting to threads. So when you're deploying AI agents, connecting them to Slack is usually the first thing clients ask about. Makes sense. Meet people where they already are.

OpenClaw's Slack integration is production-ready and I'd say it's one of the more thoughtfully designed channel setups I've worked with. It supports both direct messages and channels, handles access control properly, and offers two deployment modes depending on your infrastructure preferences. The official Slack channel documentation covers every configuration option, but let me walk through the practical side of getting this running.

Two Ways to Connect - Socket Mode vs HTTP

OpenClaw gives you two choices for how your Slack app communicates with the OpenClaw gateway: Socket Mode and HTTP Events API mode. Socket Mode is the default and it's what I'd recommend for most setups.

Socket Mode uses a WebSocket connection. Your OpenClaw gateway connects outbound to Slack's servers. No inbound firewall rules needed, no public URLs to expose, no SSL certificates to manage. You create an App Token with connections:write scope, and the gateway uses it to establish and maintain the connection.

HTTP Events API mode works the traditional way - Slack sends HTTP requests to a URL you expose. You need a public endpoint, SSL, and you configure Slack to point its Event Subscriptions, Interactivity, and Slash Commands at the same webhook path (default /slack/events). You also need a Signing Secret so OpenClaw can verify incoming requests are genuinely from Slack.

When do you use HTTP mode? Mainly when you're running multiple Slack accounts through the same OpenClaw instance and need per-account webhook paths. Or when your infrastructure team has specific requirements about how external services connect. For everyone else, Socket Mode is simpler to set up and maintain.

Setting Up Socket Mode - Step by Step

Here's the actual process:

1. Create your Slack app. Head to api.slack.com/apps, create a new app for your workspace. In the app settings, enable Socket Mode. This generates your App Token (starts with xapp-). Make sure it has the connections:write scope.

2. Install the app to your workspace and copy the Bot Token (starts with xoxb-). You'll need both tokens.

3. Subscribe to bot events. This is where you tell Slack what events to forward to your agent. The list you need:

• app_mention - when someone @mentions your bot
• message.channels, message.groups, message.im, message.mpim - messages in public channels, private channels, DMs, and group DMs
• reaction_added, reaction_removed - emoji reactions
• member_joined_channel, member_left_channel - membership changes
• channel_rename - channel name changes
• pin_added, pin_removed - pinned messages

Also enable the Messages Tab under App Home. This lets users send DMs to your bot.

4. Configure OpenClaw. In your OpenClaw config:

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

Or use environment variables if you prefer: SLACK_APP_TOKEN and SLACK_BOT_TOKEN. These only apply to the default account though - named accounts need config-based tokens.

5. Start the gateway. Run openclaw gateway and your bot should come online in Slack within seconds.

The whole process takes maybe fifteen minutes if you've done it before. First time, budget half an hour because the Slack app configuration UI can be a bit maze-like.

Access Control - Getting This Right

This is the part that matters most in any enterprise deployment. Who can talk to your agent? Where does it respond? OpenClaw gives you granular control and I think it strikes a good balance between flexibility and security.

DM Policies

The channels.slack.dmPolicy setting controls who can DM your bot:

• pairing (default) - users need to run a pairing command (openclaw pairing approve slack <code>) before the bot responds to their DMs. Good for controlled rollouts.
• allowlist - only specific users can DM the bot. You define the list.
• open - anyone in the workspace can DM the bot. Requires allowFrom to include "*".
• disabled - no DMs at all. Bot only works in channels.

For most client deployments, I start with pairing mode during the pilot phase. It naturally limits who's using the bot while still making it easy for approved users to get started. Once you're confident the agent is behaving well, switch to allowlist or open depending on your risk tolerance.

Group DMs are disabled by default (dm.groupEnabled: false). I'd leave them off unless you have a specific use case. Group DMs with AI agents can get messy when multiple people are asking questions simultaneously and the agent tries to context-switch between them.

Channel Policies

For channel access, channels.slack.groupPolicy controls the behaviour:

• open - bot responds in any channel it's added to
• allowlist - bot only responds in channels you've explicitly listed
• disabled - no channel support

Use stable channel IDs in your allowlist, not channel names. Names change. IDs don't. OpenClaw resolves channel names to IDs at startup when it has token access, but building your config around IDs is more reliable.

By default, channel messages are mention-gated. The bot only responds when someone @mentions it or replies in a thread the bot started. This is good default behaviour. Nobody wants a bot chiming in on every message in a channel. You can override this per channel with requireMention: false, but think carefully before you do.

Per-Channel Configuration

This is where OpenClaw's design gets properly useful. You can configure different behaviour per channel:

{
  channels: {
    slack: {
      channels: {
        "C0123ABCDEF": {
          requireMention: true,
          users: ["U123", "U456"],       // only these users trigger the bot
          allowBots: false,               // ignore messages from other bots
          skills: ["support", "search"],  // limit which agent skills are available
          systemPrompt: "You are a support agent for the engineering team.",
        },
      },
    },
  },
}

For a client with multiple departments using the same Slack workspace, we set up different channels with different agent personalities and skill sets. The #customer-support channel got a customer-facing agent with polite, careful responses. The #engineering-ops channel got a more technical agent with access to deployment tools. Same OpenClaw instance, same Slack workspace, different behaviour per channel.

Commands and Slash Behaviour

OpenClaw supports Slack slash commands but they're not enabled by default. You need to explicitly turn them on:

{
  channels: {
    slack: {
      commands: {
        native: true,
      },
    },
  },
}

Then register the matching slash commands in your Slack app configuration. One quirk: Slack reserves /status, so the agent status command needs to be registered as /agentstatus instead.

The argument menus for slash commands adapt nicely - up to 5 options render as buttons, 6-100 as a dropdown, and beyond 100 it switches to an async search-based selector. It's a small detail but it means the UI stays usable regardless of how many options your commands have.

Interactive Replies

OpenClaw can render interactive elements - buttons, menus, that sort of thing - in agent replies. This is disabled by default and you opt in with:

{
  channels: {
    slack: {
      capabilities: {
        interactiveReplies: true,
      },
    },
  },
}

I'd enable this for agents that handle workflows. Instead of the user having to type "approve" or "reject", they get buttons. It reduces friction and cuts down on the agent misinterpreting free-text responses.

Token Model - Understanding What Goes Where

The token setup can be confusing if you're not familiar with Slack's auth model. Quick breakdown:

• Bot Token (xoxb-) - required for both modes. This is the main token your agent uses.
• App Token (xapp-) - required for Socket Mode only. Establishes the WebSocket connection.
• Signing Secret - required for HTTP mode only. Verifies incoming requests.
• User Token (xoxp-) - optional, config-only. Defaults to read-only. Used for actions that need to happen "as a user" rather than as the bot.

If you want your bot's outgoing messages to show a custom name and icon (rather than the default bot identity), add the chat:write.customize scope to your bot token. The icon_emoji setting uses standard :emoji_name: format.

Lessons From Production Deployments

Start with DMs, expand to channels. DMs are a safer starting point because problems are contained to one user. Once the agent is reliable in DMs, add it to a single channel. Then expand.

Monitor thread behaviour. In channels, the bot auto-responds in threads it started. This is usually what you want, but watch for threads that go off-topic. The agent will keep responding because it thinks the thread is still its conversation.

Plan for multi-account setups. If your organisation has multiple Slack workspaces (common with acquisitions or large organisations), OpenClaw supports named accounts. Each account gets its own tokens and configuration. Named accounts inherit from the global channels.slack config but can override any setting.

Test your access controls thoroughly. Before going live, actually try messaging the bot from an unauthorised user. Try messaging from a channel not in your allowlist. Make sure the agent properly ignores what it should ignore. I've seen configs that looked correct but had a wildcard in the wrong place, giving everyone access during what was supposed to be a pilot.

At Team 400, we run OpenClaw deployments for organisations across Australia, including production Slack integrations handling thousands of messages per week. If you're looking to get AI agents into your team's Slack workspace, we offer managed OpenClaw services that handle the setup, monitoring, and ongoing configuration for you.

For organisations building broader agentic automation strategies, Slack is usually just the starting point. The same OpenClaw instance can connect to WhatsApp, Teams, Discord, and web chat simultaneously - one agent, multiple channels, consistent behaviour across all of them.