Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When running OpenClaw with multiple Discord bot accounts (multi-account setup), slash commands are
successfully registered for the default Discord account but are entirely absent for any
secondary account. The secondary bot responds to chat messages normally, confirming the token,
applicationId, and guild binding are all valid — but Discord's Integration settings show
"This application has no commands" for the secondary bot, and no slash commands appear in-server.

All documented steps for multi-account Discord configuration have been followed, including setting a
per-account applicationId as required by the docs. The issue does not appear to be a configuration
error — it is consistent across re-invites and permission resets.

Steps to reproduce

1. Configure two Discord bots under channels.discord.accounts — one default, one named (e.g. ray):

"channels": {
  "discord": {
    "enabled": true,
    "accounts": {
      "default": {
        "applicationId": "<DEFAULT_BOT_APPLICATION_ID>",
        "guilds": {
          "<GUILD_ID_A>": {
            "requireMention": false,
            "users": ["<OWNER_USER_ID>"],
            "channels": {
              "<CHANNEL_ID_A>": { "enabled": true }
            }
          }
        }
      },
      "ray": {
        "token": "${DISCORD_BOT_TOKEN_RAY}",
        "applicationId": "<SECONDARY_BOT_APPLICATION_ID>",
        "guilds": {
          "<GUILD_ID_B>": {
            "requireMention": false,
            "users": ["<OWNER_USER_ID>"],
            "channels": {
              "<CHANNEL_ID_B>": { "enabled": true }
            }
          }
        }
      }
    }
  }
}

2. Bind each account to its respective agent via bindings[]:

"bindings": [
  {
    "agentId": "agent-one",
    "match": {
      "channel": "discord",
      "accountId": "default",
      "peer": { "kind": "channel", "id": "<CHANNEL_ID_A>" },
      "guildId": "<GUILD_ID_A>"
    }
  },
  {
    "agentId": "agent-two",
    "match": {
      "channel": "discord",
      "accountId": "ray",
      "peer": { "kind": "channel", "id": "<CHANNEL_ID_B>" },
      "guildId": "<GUILD_ID_B>"
    }
  }
]

3. Set commands.native to "auto" (default — applies to Discord):

"commands": {
  "native": "auto"
}

4. Start or reload the OpenClaw gateway.
5. Invite both bots to their respective Discord guilds with identical permissions (Send Messages,
   Use Slash Commands, etc.).
6. In Discord: Server Settings → Integrations — inspect each bot's command list.

Expected behavior

Both bots should have their slash commands registered with Discord on gateway startup. The secondary
bot (ray account) should show the same full command set in Server Settings → Integrations as
the default bot, since both accounts are fully configured with valid tokens and applicationId
values, and commands.native: "auto" applies globally to Discord.

Actual behavior

• default bot: All OpenClaw slash commands are registered and visible in Discord Integrations. ✅
• ray (secondary) bot: Discord Integrations shows "This application has no commands." ❌
  The bot is functional — it receives messages and responds to chat — but slash commands are
  completely absent. No registration errors are visible in the gateway logs at info level.

Attempted mitigations, all unsuccessful:

1. Removed bot from guild and re-invited with fresh OAuth2 URL.
2. Verified both bots have identical permission sets in Discord Developer Portal and guild settings.
3. Confirmed applicationId is set correctly under the named account
   (channels.discord.accounts.ray.applicationId) as documented.

OpenClaw version

2026.5.3-1

Operating system

Linux Mint 22.3

Install method

npm global

Model

kimi/kimi-code

Provider / routing chain

kimi

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Gateway log level is `info` with `redactSensitive: "tools"`. No errors or warnings appear at startup
related to the `ray` account's command registration. The `default` account logs normal command
registration confirmation; the `ray` account produces no equivalent log output, suggesting the
registration step is either silently skipped or not attempted for non-default accounts.

**Relevant gateway config excerpt (IDs redacted):**


"channels": {
  "discord": {
    "enabled": true,
    "streaming": { "mode": "off" },
    "commands": { "native": true },
    "eventQueue": { "listenerTimeout": 120000 },
    "inboundWorker": { "runTimeoutMs": 1800000 },
    "accounts": {
      "default": {
        "applicationId": "<DEFAULT_BOT_APPLICATION_ID>",
        "guilds": {
          "<GUILD_ID_A>": {
            "requireMention": false,
            "users": ["<OWNER_USER_ID>"],
            "channels": {
              "<CHANNEL_ID_A>": { "enabled": true }
            }
          }
        }
      },
      "ray": {
        "token": "${DISCORD_BOT_TOKEN_RAY}",
        "applicationId": "<SECONDARY_BOT_APPLICATION_ID>",
        "guilds": {
          "<GUILD_ID_B>": {
            "requireMention": false,
            "users": ["<OWNER_USER_ID>"],
            "channels": {
              "<CHANNEL_ID_B>": { "enabled": true }
            }
          }
        }
      }
    }
  }
}


**Top-level commands config:**


"commands": {
  "native": "auto",
  "nativeSkills": "auto",
  "restart": true,
  "ownerDisplay": "raw"
}

Impact and severity

The secondary bot is fully operational for conversational use, so no data loss or agent failure
occurs. However, the absence of slash commands on non-default accounts makes multi-bot setups a
second-class citizen — operators lose access to all /new, /reset, /compact, /think,
/status, /restart, and other critical control commands on any bot beyond the first. In
production multi-agent configurations where each agent has a dedicated Discord bot, this effectively
breaks the command interface for all agents except one.

Additional information

• The two bots are in different guilds, ruling out any guild-level conflict or deduplication issue.
• Both bots are confirmed distinct applications in the Discord Developer Portal (different
  applicationId values), so this is not a token aliasing / deduplication scenario (the docs note
  that if two accounts resolve to the same token, only one monitor starts — that is not the case here).
• The docs state: "A top-level channels.discord.applicationId is inherited by accounts, so only
  set it there when every account should use the same application ID." Both bots have distinct IDs
  set at the per-account level, which is the correct pattern per documentation.
• Suspected root cause: the Discord plugin's slash command registration loop may only iterate over
  the default account, or the per-account registration path has a bug that causes it to silently
  no-op when accountId !== "default". Adding debug-level logging around the command registration
  phase would help confirm.
• Setting channels.discord.commands.native: false and back to true (or "auto") on a reload
  does not trigger re-registration for the secondary account.