openclaw - 💡(How to fix) Fix Discord multi-account startup should prioritize the configured primary/default account [1 comments, 2 participants]

Summary

In a live multi-account Discord install, the configured primary/front-desk account can start after specialist accounts. A local installed-dist patch is still required after upgrading to OpenClaw 2026.5.5 with @openclaw/discord 2026.5.6 to ensure the primary account starts first.

This is related to, but not fully covered by, the duplicate-token issue in #78118. #78118 focuses on suppressing duplicate enabled accounts that resolve to the same bot token. This issue is narrower: when multiple distinct Discord bot accounts are enabled, OpenClaw should start the configured primary/default account first so the front desk is available immediately and restart windows do not make specialist apps appear to own the install.

Environment

• OpenClaw: 2026.5.5 (b1abf9d)
• Discord plugin package: 2026.5.6
• Platform: macOS arm64
• Gateway: LaunchAgent, loopback local gateway
• Discord accounts: main/Jarvis as front desk, plus specialist apps (billy, scout, farber, maverick, lumbergh)
• channels.discord.defaultAccount: main

Expected behavior

The primary/default Discord account should start first, then specialists should start under the existing stagger.

Example intended order:

main:      immediate
billy:     +10s
farber:    +20s
lumbergh:  +30s
...

Actual behavior / local evidence

The existing startup delay calculation can order accounts by config/object order rather than primary/default priority. In this install, a local patch is still applied after the 2026.5.5 upgrade:

discord-startup-priority: unchanged
file: /Users/jarviskar/.openclaw/npm/node_modules/@openclaw/discord/dist/channel-D8E-S2xn.js

The patch preserves the upstream stagger and adds a priority sort before computing each account's delay:

const DISCORD_ACCOUNT_STARTUP_PRIORITY = ["main", "default", "billy"];

// then sort candidate account ids by that priority before findIndex(...)

This is intentionally not a security relaxation: specialist accounts remain allowlisted, direct specialist access stays narrow, and generic native commands remain disabled on specialist apps. It only makes the front-desk bot start first.

Why this matters

For live Discord installs, restart/upgrade windows are user-visible. If specialist accounts start first while the front-desk account is delayed, the install appears misrouted or partially broken. This is especially confusing when users have recently been debugging native slash-command ownership and Discord client command caches.

Even if duplicate-token suppression from #78118 is fixed on current main, startup order remains a separate operational UX issue for multi-account installs with distinct bot tokens.

Suggested fix

Prefer deriving startup priority from config rather than hard-coded account ids:

1. Start channels.discord.defaultAccount first if enabled.
2. Then start main/default aliases when applicable and distinct.
3. Then start remaining enabled accounts in a stable order while preserving the existing stagger.
4. Add a regression test for account delay ordering when defaultAccount is not first in object/config order.

Local verification after patch/restart

openclaw gateway status: runtime running, connectivity probe ok
openclaw tasks list --status running --json: count 0
openclaw health --json: ok true, Discord accounts connected after stagger completes

Operators should not need to patch @openclaw/discord/dist/channel-*.js after each upgrade to get deterministic front-desk-first startup behavior.