The structural case for Discord (channel-per-agent, threads-per-subtask) is covered in §4.1. This article is the mechanical half: the four moments where every guide goes wrong, in order. The two intents that have to be on before the token is generated. Developer Mode that has to be on before channel IDs are copyable. openclaw configure from the terminal, not via the agent. And the gateway restart that has to complete before you assume anything is wired up. Every later debugging session in your Discord life traces back to one of these four being skipped. The source video is the same VfmG9Q69p1o from §4.1; this article zooms into the bits the broader walkthrough glosses over.

What you'll learn

  • The two Discord intents — Server Members Intent and Message Content Intent — are off by default and have to be flipped before you save the Bot page. If you save without them, the bot appears online but reads zero messages.
  • Developer Mode in Discord is off by default. Without it, "Copy Channel ID" doesn't appear on the right-click menu and you cannot paste a channel ID into openclaw configure. Turn it on first.
  • The openclaw configure CLI flow is the reliable path. Asking the agent to wire Discord for you works ~1 time in 4 — the host tested both.
  • The OAuth2 invite URL has three required pieces: scope bot, scope applications.commands, and install type Guild Install (not global). Use Administrator for personal setups; tighten permissions for shared servers.
  • openclaw gateway restart has to complete before you test the bot. The bot appearing online in your member list is the verification, not the OAuth2 authorize step.
  • The token is a private key — treat it like a password, store in ~/.openclaw/.env, rotate immediately if exposed.
  • Why the bot works locally via the CLI but breaks on a VPS without proper gateway persistence, and the systemd / supervisor pattern that fixes it.
  • The "gateway doesn't come back after a config change" failure mode and the three-step recovery (gateway restart → openclaw update → manual token reset).

Why the two intents exist (and why they're off by default)

Discord introduced Privileged Gateway Intents in 2020 as a privacy-and-scaling response to abuse. Bots that want to receive the full event stream (member joins, presence updates, message contents) have to opt in explicitly. The intents exist so Discord can rate-limit and audit bots that need the full stream; they're off by default so a casual bot can't silently slurp every message in a server it joins.

For an OpenClaw agent, the two intents are non-negotiable:

  • Server Members Intent — needed if the bot wants to know who is in the server, who is in a specific role, or who has permission to interact with it. OpenClaw's pairing policy (Allowlist mode) checks this intent to verify a user's identity before responding.
  • Message Content Intent — needed to read the actual content of messages. Without this intent, the bot sees "someone sent a message" but not what the message says. This is the one that makes the bot effectively deaf. Most "the bot doesn't reply" complaints trace to this intent being off.

The third intent, Presence Intent, is optional but recommended. It lets the bot see who is online and what their status is. OpenClaw uses it for the "currently active users" list and to prioritise responses when multiple users are talking.

Common symptom of a missing intent: the bot is online (green dot in member list), but doesn't respond to anything — not @mention, not a normal message, not a slash command. The bot looks alive but reads nothing. The fix is one toggle and one save.

The four moments every guide gets wrong

1. The two intents (the #1 mistake in the source video)

The single most common stuck-step in the BoxminingAI Discord flow, called out by the host explicitly: you save the Bot page without enabling both intents, and the bot "looks" online in your server but reads zero messages. The symptom looks identical to "the bot is broken" — it isn't, you just need to flip two switches.

Step-by-step:

  1. Go to discord.com/developers/applications and select your application.
  2. In the left sidebar, click Bot.
  3. Scroll down to Privileged Gateway Intents.
  4. Enable both:
    • Server Members Intent — lets the bot see server member information.
    • Message Content Intent — lets the bot read message content. This is the one the host calls out as the load-bearing intent; without it, your bot literally cannot read what you type.
  5. (Optional but recommended) Presence Intent — for online status.
  6. Click Save Changes. If you change intents after the token has been issued, you may need to re-copy the token.

The host's framing is direct: "out of three times out of four, if I just kept talking to my agent and tell him to set up Discord, it just blows up." The bot setup is the first place this shows up. Don't trust the bot to wire itself; do it from the terminal.

2. Developer Mode (the channel-ID gotcha)

Channel IDs are how openclaw configure knows which Discord channels the bot should monitor. They look like long numbers (e.g. 1234567890123456789). You can't see them in the Discord UI unless Developer Mode is on, and Developer Mode is off by default.

Step-by-step:

  1. Open Discord.
  2. Click the gear icon (User Settings) in the bottom-left.
  3. Scroll down to App Settings → Advanced in the left sidebar.
  4. Toggle Developer Mode on.
  5. Close settings.

Verification: right-click any channel name in your server. You should now see Copy Channel ID in the context menu. If you don't, Developer Mode didn't take. Toggle it off and on again.

Once Developer Mode is on, right-click each channel you want the bot to read and Copy Channel ID. Paste each ID into the openclaw configure prompt when asked for a channel ID. The host emphasises: do this before you start configuring, not after.

Why Discord hides channel IDs by default: they're internal identifiers, not user-facing. Discord treats them as API plumbing — useful for bot developers, irrelevant to casual users. The Developer Mode toggle is the explicit opt-in to "show me the developer-facing details." Most users never need it; any OpenClaw user does.

The channel ID looks like 1234567890123456789 — a 17-to-20-digit integer (snowflake). Discord's snowflake format encodes the timestamp, the worker ID, and the sequence number into a single integer, which is why channel IDs are unique across all of Discord and don't need a server prefix. You can paste them into openclaw configure as plain integers.

A subtle gotcha: channel IDs change when channels are renamed or moved between categories, but not when channels are simply archived or have their permissions edited. If you reorganise your server (drag channels into a new category), the bot will start missing messages until you re-paste the new IDs. Treat any server restructure as a "re-paste channel IDs" trigger.

3. The openclaw configure flow (terminal, not agent)

The reliable path. The host tested both setup methods and the local CLI flow won decisively.

Step-by-step:

  1. SSH into your OpenClaw installation (Termius, or local terminal).

  2. Run:

    openclaw configure

  3. Select Local when prompted for environment.

  4. Navigate to Channels → Configure.

  5. Select Discord.

  6. When prompted for Discord bot token, paste your token:

    • Windows: Ctrl + Shift + V
    • Mac: Cmd + V
    • Linux: Ctrl + Shift + V or right-click → Paste

  7. Answer Yes to configure Discord to access channels.

  8. For each channel you want the bot to read, paste the channel ID you copied in step 2.

  9. Configure pairing:

    • Allow DM pairing: choose based on your needs.
    • Pairing policy: Open / Pairing codes / Allowlist. Pick by security level.

  10. Select Finished when done, then Continue to save.

Why manual beats the agent path: the host says the chat-based setup "blows up" three times out of four. Manual is more reliable (works 100% of the time vs ~75% with the agent), gives clearer error messages, and avoids the agent misconfiguring itself. If you must use the agent path, start a fresh session with cleared context and be very specific.

4. The gateway restart (and the OAuth2 invite)

Two steps, in this order:

Step A — Restart the gateway. After openclaw configure saves:

openclaw gateway restart

Wait for confirmation that the gateway has restarted successfully. If the command hangs or returns an error, see the §4.3 gateway-recovery flow.

Step B — Generate the OAuth2 invite URL. Back in the Developer Portal:

  1. Click OAuth2 in the left sidebar.
  2. Click URL Generator.
  3. Scopes — tick both:
    • bot
    • applications.commands
  4. Bot permissions — for a personal setup, the host picks Administrator and says the exact permission set "doesn't really matter that much." For shared servers, tighten to: Send Messages, Send Messages in Threads, Embed Links, Attach Files, Read Message History, Add Reactions, Use Slash Commands.
  5. Integration type — pick Guild Install (not a global install — you're putting the bot on your own private server).
  6. Copy the generated URL at the bottom.

Step C — Authorize. Paste the invite URL in your browser, select your server from the dropdown, click Continue, review permissions, click Authorize, complete the CAPTCHA.

The verification moment: after authorize, the bot should appear in your server's member list as online. That is the signal the gateway and the bot are both working. If the bot is offline or grey, do not proceed — the rest of the steps (channel configuration, pairing, testing) will silently fail.

Configuration patterns

The channel-per-agent pattern (from §4.1) means each Discord channel maps to one bot. The pattern from the host's own team (Avengers-themed):

# Stark (Development)
Channel: #stark-dev
Pairing: Allowlist

# Banner (Research)
Channel: #banner-research
Pairing: Allowlist

# Jarvis (General)
Channel: #jarvis-general
Pairing: Open

The pairing policy is the safety rail. Open means anyone in the server can interact with the bot; Allowlist restricts to a list of approved user IDs; Pairing codes requires a one-time code from openclaw tui to pair a new user. The host's team uses Allowlist for most bots and Open only for the general-purpose one.

For team collaboration, multiple members can share the same bot:

# Main agent channel
Channel: #team-agent
Pairing: Allowlist (team members only)

# Subtask channels
Channel: #presentations
Channel: #research
Channel: #code-review

Multiple bots in one server

You can run multiple OpenClaw instances, each with its own Discord bot, in a single server:

  1. Create multiple Discord applications (one per bot).
  2. Configure each with OpenClaw using different channel IDs.
  3. Each bot operates independently in its assigned channel — no cross-talk because each bot only reads its own channel.

The pairing policy applies per bot, not per server. You can have an Open Jarvis and an Allowlist Stark in the same server.

Gateway supervision (don't lose the bot at 3am)

On a local install, the gateway runs in your terminal session. Close the terminal, the bot goes offline. On a VPS install, the gateway should be supervised — managed by a process supervisor that restarts it if it dies.

The two common supervisors are systemd (the default on most Linux distributions) and supervisor (a Python-based process manager). Systemd is the standard; use it unless you have a specific reason not to.

A minimal systemd unit for the OpenClaw gateway:

[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=openclaw
WorkingDirectory=/home/openclaw
ExecStart=/usr/local/bin/openclaw gateway start
Restart=on-failure
RestartSec=10s
EnvironmentFile=/home/openclaw/.openclaw/.env

[Install]
WantedBy=multi-user.target

Drop this into /etc/systemd/system/openclaw-gateway.service, then:

sudo systemctl daemon-reload
sudo systemctl enable openclaw-gateway
sudo systemctl start openclaw-gateway
sudo systemctl status openclaw-gateway

The Restart=on-failure directive is the load-bearing line — if the gateway crashes, systemd restarts it after 10 seconds. The EnvironmentFile directive pulls secrets from ~/.openclaw/.env without putting them in the unit file. The After=network.target directive ensures the gateway starts after the network is up, so it doesn't try to connect to Discord before the network is ready.

Verification: sudo systemctl status openclaw-gateway should show active (running). Reboot the VPS — the gateway should come back automatically. If it doesn't, the unit isn't enabled correctly.

The host's framing: "the gateway doesn't start up again after a bad config" is the #1 failure mode. Supervision doesn't prevent the bad config, but it does prevent the bad config from cascading into a 3am outage where you wake up to a silent bot.

Try it yourself

The hands-on goal: a Discord bot online in your server, both intents enabled, reading at least one channel, replying to messages.

  1. Turn on Developer Mode. Open Discord → User Settings → Advanced → Developer Mode → on. Verify by right-clicking a channel and confirming "Copy Channel ID" appears.
  2. Create the bot. Go to discord.com/developers, click New Application, name it (e.g. OpenClaw Agent), accept the ToS, click Create.
  3. Enable both intents. Move to the Bot tab, scroll to Privileged Gateway Intents, enable Server Members Intent + Message Content Intent (+ Presence Intent if you want online status), click Save Changes.
  4. Copy the token. Click Reset Token (verify with 2FA if prompted), copy the token once into a password manager. You will not see it again.
  5. Wire the bot to OpenClaw locally. In your terminal: openclaw configure → Local → Channels → Configure → Discord → paste token → Yes to channels → paste channel IDs → pick pairing policy → Finished → Continue.
  6. Restart the gateway. openclaw gateway restart. Wait for confirmation.
  7. Generate the OAuth2 URL. Developer Portal → OAuth2 → URL Generator → tick bot + applications.commands → pick permissions (Administrator for personal) → Guild Install → copy URL.
  8. Authorize. Paste URL in browser, pick server, Authorize, complete CAPTCHA. Verify the bot is online in your member list.
  9. Test it. Go to the bot's channel, send @YourBot hello or just hello. It should respond within a few seconds. If silent, see §4.3 for the /always-reply fix.

Common pitfalls

  • Saving the Bot page without both intents. The #1 mistake. The bot looks online but reads zero messages. Symptom: "the bot doesn't reply." Cause: intents. Fix: re-enable both, save, re-copy the token, re-paste into openclaw configure, restart the gateway.
  • Not enabling Developer Mode first. The channel-ID step fails silently because the right-click menu has no "Copy Channel ID" option. The host calls this out as the most common stuck-step. Enable Developer Mode before you start configuring, not after.
  • Asking the agent to wire Discord for you. The host tested both paths and the chat-based setup "blows up" three times out of four. Use openclaw configure from the terminal; the conversational path is a coin flip.
  • Skipping the gateway restart. Configuration changes don't apply until openclaw gateway restart completes. If you skip this step, nothing you configured will take effect.
  • Authorizing before the gateway is up. The bot shows in your member list as offline if the gateway is down. Don't proceed past authorize until the bot is online.
  • Using a global OAuth2 install. For personal setups, you want the bot on your own server, not globally distributed. Pick Guild Install.
  • Committing the bot token to git or sharing it in chat. The token is a private key. If it's exposed, go to the Developer Portal → Bot → Reset Token immediately, update ~/.openclaw/.env, restart the gateway.
  • Pasting your existing Minimax coding key into the bot config. Different wallet — keep bot tokens and model API keys in separate config blocks.
  • Picking Administrator for a shared server. For personal setups the host says it "doesn't really matter," but for shared servers tighten to specific permissions (Send Messages, Embed Links, etc.).
  • Using the bot without configuring pairing. Default pairing is Open, which means anyone in the server can interact with the bot. For any non-personal use, configure pairing first.

Sources

  • Setup OpenClaw with Discord (Complete Guide) — 7,682 views · video_id: VfmG9Q69p1o
  • Supabase query (project ttxdssgydwyurwwnjogq): SELECT video_id, title, views, summary_content, summary_key_takeaways, transcript_content FROM public.videos WHERE video_id = 'VfmG9Q69p1o';
  • External references: Discord Developer Portal (discord.com/developers/applications), OpenClaw CLI (openclaw configure, openclaw gateway restart), OAuth2 URL Generator, the two Privileged Gateway Intents documentation.