Skip to content
Topics
openclaw
OpenClaw Discord Setup: DM Pairing, Guild Channels, and Voice

OpenClaw Discord Setup: DM Pairing, Guild Channels, and Voice

Updated on

Set up OpenClaw with Discord using a bot token, DM pairing, guild allowlists, mention rules, and optional voice channels. A practical guide to getting a private Discord workspace running safely.

If you want to use OpenClaw with Discord, the fastest safe path is: create a Discord bot, set the bot token on the machine running OpenClaw, start the gateway, approve the first DM pairing, then turn your private server into a guild workspace.

That is the setup path that matters because OpenClaw on Discord is not just "one more bot." Each Discord channel can become its own agent session with its own context, approvals, and routing rules. If you skip the pairing, allowlist, and mention settings, the setup usually feels broken even when the bot token is valid.

If you searched for OpenClaw Discord docs, the primary official source is the OpenClaw Discord channel guide: Discord setup docs (opens in a new tab). This page is the practical layer on top: what to configure first, what to keep private, and how to get from a DM test to a usable private Discord workspace.

If you need the broader product framing first, read NVIDIA NemoClaw vs OpenClaw vs ZeroClaw: Differences, Pi Agent, and Nanobot in 2026. If your real goal is repo-local coding help rather than a Discord-based assistant, How to Use Codex and How to Use OpenCode are the better starting points.

Quick answer: what is the fastest way to get OpenClaw working in Discord?

Your situationBest first stepWhy
You only want to verify the bot worksSet the token, start the gateway, and pair in Discord DMThis gives you the shortest path to a working reply loop
You want a private Discord workspace with multiple channelsAfter DM pairing, add your server to the guild allowlistThis lets each channel become its own isolated OpenClaw session
You want the bot to reply without @mention in your own serverSet requireMention: false for that guildThis makes the server feel like a real assistant workspace instead of a bot command channel
You want realtime voice in DiscordConfigure channels.discord.voice after text worksVoice is useful, but it is not the right first debugging layer

The reliable setup order is:

  1. create the Discord bot
  2. enable the required intents
  3. set the bot token securely
  4. start the gateway
  5. approve the first DM pairing
  6. add your server to the guild allowlist
  7. decide whether replies should require @mention
  8. add voice only after text chat is stable

What OpenClaw on Discord actually gives you

OpenClaw on Discord is not just a single shared bot memory.

According to the current OpenClaw docs, Discord supports:

  • DMs
  • guild text channels
  • forum-channel thread workflows
  • native command handling
  • approval buttons
  • optional voice-channel sessions

That matters because the real product shape is a Discord workspace of agent sessions, not only a DM bot.

In practice, that means:

  • Discord DMs can act as your first low-risk pairing channel
  • each guild channel can keep separate context
  • approvals and routing stay tied to the Discord surface where the request happened
  • voice can be layered on later if you want continuous conversations

Quick Start

The official Discord docs recommend creating a bot, setting the token, then starting the gateway. The practical minimal version looks like this:

export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN"
openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json
openclaw gateway

If OpenClaw is already running as a background process, restart the gateway instead of launching a second copy.

Then DM your bot in Discord and approve the pairing code.

That is the shortest path from "I have a Discord bot token" to "OpenClaw is actually reachable in Discord."

Step 1: Create the Discord bot correctly

In the official Discord setup docs (opens in a new tab), OpenClaw recommends a standard Discord bot flow:

  1. go to the Discord Developer Portal
  2. create a new application
  3. add a bot
  4. copy the bot token

For the OAuth URL, the baseline scopes are:

  • bot
  • applications.commands

The common baseline permissions are:

  • View Channels
  • Send Messages
  • Read Message History
  • Embed Links
  • Attach Files

Avoid Administrator unless you really need it. A private server with minimal permissions is a better default.

Step 2: Enable the right intents before you debug anything else

This is one of the easiest ways to lose time.

The OpenClaw Discord docs call out these intents:

  • Message Content Intent: required
  • Server Members Intent: recommended, and required for role allowlists and name matching
  • Presence Intent: optional

If the bot joins the server but behaves strangely, missing intents are one of the first things to verify.

Step 3: Keep the token out of chat

Your Discord bot token is a secret. Do not paste it into a chat with the agent.

Use an environment variable or a SecretRef-backed config path on the machine running OpenClaw. The docs explicitly recommend setting the token locally, then wiring config to that local secret.

This is the safe baseline:

export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN"
openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json

Then start the gateway:

openclaw gateway

If text chat does not work after this, stop and debug the token, intents, and gateway before you touch guild policies.

Step 4: Pair in Discord DM first

OpenClaw's current Discord docs treat DMs as the easiest first checkpoint.

The practical flow is:

  1. make sure the gateway is running
  2. DM the bot in Discord
  3. wait for the pairing code
  4. approve that code from an existing OpenClaw channel or via CLI

Why start with DM pairing:

  • it is the shortest loop to validate the bot token and routing
  • it removes guild-level policy from the first test
  • it lets you prove the bot is alive before you turn a whole server into a workspace

If your first DM never gets a response, do not move on yet. The problem is usually one of:

  • the token is wrong
  • the gateway is not running
  • DMs are blocked
  • intents are incomplete

Step 5: Turn a private Discord server into a guild workspace

Once DM pairing works, the next useful move is not "add more channels everywhere." It is "set up one private Discord server the right way."

The official docs recommend a guild workspace because each channel gets its own isolated OpenClaw session. That is the real reason Discord is interesting here. You can create channels like:

  • #coding
  • #research
  • #home
  • #ops

and each one can hold different context.

The first config move is to add your server to the guild allowlist:

{
  channels: {
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        YOUR_SERVER_ID: {
          requireMention: true,
          users: ["YOUR_USER_ID"],
        },
      },
    },
  },
}

This is the safer default because it limits where the bot will respond and who can use it.

Step 6: Decide whether your server should require @mention

By default, OpenClaw on Discord is safer than convenient.

That is usually correct for shared servers. But in a private server where it is just you and your bot, requiring @mention on every message makes the workspace feel clumsy.

The docs show that you can disable mention-only behavior for a specific guild:

{
  channels: {
    discord: {
      guilds: {
        YOUR_SERVER_ID: {
          requireMention: false,
        },
      },
    },
  },
}

Use this only in trusted servers. If the server is shared, keep mention requirements on.

Step 7: Understand the memory model before you expect "shared context"

This is one of the most important conceptual details in the Discord docs.

OpenClaw does not treat every Discord conversation as one giant shared memory pool.

The docs note that:

  • DMs can collapse into the main agent session
  • guild channels are isolated sessions
  • long-term memory is not automatically loaded into every guild channel the same way

That means you should not expect #research and #home to automatically feel like the same assistant thread. That isolation is useful, but only if you know it is there.

If you need stable shared instructions everywhere, keep them in the global agent instruction layer rather than assuming channel memory will carry them.

Add voice only after text chat works

OpenClaw also supports Discord voice channels, but that should come after text is already stable.

The docs say voice requires:

  • native commands enabled
  • channels.discord.voice configured
  • Connect and Speak permissions in the target voice channel

A minimal auto-join shape looks like this:

{
  channels: {
    discord: {
      voice: {
        enabled: true,
        autoJoin: [
          {
            guildId: "123456789012345678",
            channelId: "234567890123456789",
          },
        ],
      },
    },
  },
}

This is powerful, but it is not your first milestone. First make sure:

  • DM pairing works
  • guild text routing works
  • allowlists behave the way you expect

Only then add voice.

Common traps

Sending the bot token in chat

Do not do this. Set the token locally on the machine running OpenClaw, then point OpenClaw config at that local secret.

Trying guild channels before DM pairing

If you skip the DM checkpoint, you end up debugging token, intents, gateway, guild policy, and mentions all at once.

Leaving requireMention on in a private server and assuming the bot is broken

On a private server, the bot may be healthy but still ignore messages until it is mentioned. That is policy, not failure.

Expecting one shared memory across every Discord channel

Guild channels are designed to stay isolated. That is often useful, but it surprises people who expect one global chat history.

Turning on voice before text chat works

Voice adds another debugging layer. Start with text.

Troubleshooting checklist

If OpenClaw in Discord is not responding, check these in order:

  1. the gateway is running
  2. the bot token is valid and set locally
  3. Message Content Intent is enabled
  4. DMs are allowed for pairing
  5. the server is on the guild allowlist if you are testing guild channels
  6. requireMention is configured the way you expect
  7. the sender is not blocked by user or guild policy

The OpenClaw docs also point to useful commands for diagnosis:

openclaw doctor
openclaw channels status --probe
openclaw logs --follow

When this Discord setup is the wrong starting point

Do not start here if your actual goal is:

  • a repo-local coding assistant
  • a zero-UI runtime for embedded deployment
  • a generic comparison of OpenClaw alternatives

In those cases, these are the better reads:

FAQ

What is the first thing I should test in OpenClaw Discord setup?

Test Discord DM pairing first. It is the shortest way to confirm that your token, gateway, and basic routing work.

Do I need @mention in every Discord channel?

Not always. On private servers, many users will want requireMention: false. On shared servers, keeping mention requirements on is the safer default.

Why is my OpenClaw Discord bot online but not replying?

The most common causes are a bad token, missing Message Content Intent, a stopped gateway, blocked DMs, or guild policy that prevents replies without allowlist or mention matches.

Should I enable Discord voice first?

No. Get DM pairing and guild text channels working first, then add voice.

Is this better than a generic "How to use OpenClaw" guide?

For practical search intent, yes. Discord setup has a clearer job: it helps a reader get one real integration working instead of trying to summarize the whole OpenClaw product in one page.

Related Guides

📚