openclaw - 💡(How to fix) Fix Discord per-account native command disable leaves stale specialist commands that can hijack /side [2 comments, 2 participants]

Summary

In a multi-account Discord setup, generic OpenClaw native commands such as /side can remain registered on specialist bot applications even after the specialist accounts are configured with commands.native=false and commands.nativeSkills=false.

This caused a project-channel /side invocation to route to a specialist bot application instead of the main/orchestrator bot. The specialist then rejected the interaction with This channel is not allowed., producing a confusing UX and preventing the main agent from seeing the request.

Expected behavior

When a Discord account has native commands disabled, OpenClaw should not leave previously registered native/global application commands active for that account.

For generic orchestration commands such as /side, expected behavior in a multi-account setup is one of:

• only the main/default orchestrator app registers generic native commands, or
• per-account command include/exclude config allows specialist apps to opt out of generic commands, or
• disabling native commands on a specialist reconciles Discord application commands by deleting stale registrations.

Actual behavior

The config had specialist accounts set to strict channel allowlists and later set to:

"commands": {
  "native": false,
  "nativeSkills": false
}

After restart, OpenClaw skipped deployment for those accounts, but Discord still had old global application commands registered. A native /side in a project channel was owned by the specialist application and never reached the main/orchestrator account.

The specialist handler then rejected the channel according to allowlist policy:

if (interaction.guild && channelConfig?.allowed === false && !await canBypassConfiguredAcpGuildGuards()) {
  await respond("This channel is not allowed.");
  return { accepted: false };
}

Reproduction shape

1. Configure multiple Discord bot accounts: one main/orchestrator and several specialists.
2. Allow specialist bots only in their desk/handoff channels with groupPolicy: "allowlist".
3. Let native command registration run while specialists inherit native commands.
4. Later set specialist accounts to commands.native=false and commands.nativeSkills=false.
5. Restart/reload OpenClaw.
6. In Discord, /side can still appear as registered by a specialist app because the stale global application command remains on Discord.
7. Using /side in a main project channel routes to the specialist and returns This channel is not allowed.

Local validation and workaround

A read-only Discord API registry check showed stale global commands on specialist applications even after native commands were disabled in config.

Local cleanup used Discord's application-command overwrite endpoint to clear global commands on specialist apps only. After cleanup:

• specialist apps had globalCount: 0 and no /side
• the main/default app still had /side, /steer, /commands, /help, /skill

This resolved the observed specialist hijack without weakening DM policy or broadening specialist channel access.

Environment

• OpenClaw version: 2026.5.4
• Channel: Discord
• Multi-account Discord config
• Main/default orchestrator plus specialist bots
• groupPolicy: "allowlist"
• User allowFrom configured
• Specialist channel access intentionally narrow

Suggested fix

When channels.discord.accounts.<id>.commands.native resolves to false, reconcile the app's native command surface by deleting existing registered commands for that account, or provide a supported per-account command include/exclude mechanism and document how to keep generic commands main-only.

Tests should cover toggling an account from native commands enabled to disabled and assert that stale provider-side commands are removed rather than left active.