openclaw - 💡(How to fix) Fix Bug: Discord channel silently disabled after 2026.5.18 update without plugin-entry migration [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#84360Fetched 2026-05-20 03:41:12
View on GitHub
Comments
2
Participants
2
Timeline
3
Reactions
1
Timeline (top)
commented ×2closed ×1

Updating an existing macOS install from 2026.4.29 to 2026.5.18 silently disabled Discord even though channels.discord.enabled = true remained configured and the updater installed @openclaw/discord.

The missing piece was plugins.entries.discord. Historical installs had Discord configured only under channels.discord because Discord previously worked as a core-bundled channel. In 2026.5.18, Discord appears to require a matching plugin entry, but the update did not migrate openclaw.json to add one.

Error Message

  • There was no obvious error or warning explaining that Discord was configured but not loaded.

Root Cause

This is silent user-facing channel loss. The package is installed, plugins list says enabled, and config still contains channels.discord, but the bot does not respond on Discord. The only clear diagnostic is the mismatch between plugins list, status --deep, and the gateway loaded-plugin line.

Code Example

[gateway] http server listening (11 plugins: acpx, bonjour, browser, canvas, codex, device-pair, file-transfer, memory-core, phone-control, talk-voice, telegram; ...)

---

"plugins": {
  "entries": {
    "discord": {
      "enabled": true,
      "config": {}
    }
  }
}

---

channels.<id>.enabled = true but plugins.entries.<id>.enabled is missing or false
RAW_BUFFERClick to expand / collapse

Bug: Discord channel silently disabled after 2026.5.18 update without plugins.entries.discord migration

Summary

Updating an existing macOS install from 2026.4.29 to 2026.5.18 silently disabled Discord even though channels.discord.enabled = true remained configured and the updater installed @openclaw/discord.

The missing piece was plugins.entries.discord. Historical installs had Discord configured only under channels.discord because Discord previously worked as a core-bundled channel. In 2026.5.18, Discord appears to require a matching plugin entry, but the update did not migrate openclaw.json to add one.

Environment

  • Host: macOS 14.7.4 arm64
  • Node: 25.6.1
  • Install: pnpm-global at /opt/homebrew/lib/node_modules/openclaw
  • Gateway: LaunchAgent ai.openclaw.gateway
  • From: OpenClaw 2026.4.29 (a448042)
  • To: OpenClaw 2026.5.18 (50a2481)

What happened

After update:

  • openclaw plugins list showed discord as enabled and installed from ~/.openclaw/npm/node_modules/@openclaw/discord/dist/index.js.
  • openclaw status --deep showed only Telegram under Channels. Discord was absent.
  • Gateway startup log listed 11 plugins and did not include Discord:
[gateway] http server listening (11 plugins: acpx, bonjour, browser, canvas, codex, device-pair, file-transfer, memory-core, phone-control, talk-voice, telegram; ...)
  • ~/.openclaw/openclaw.json still had a valid channels.discord block, but no plugins.entries.discord entry.
  • There was no obvious error or warning explaining that Discord was configured but not loaded.

Manual fix:

"plugins": {
  "entries": {
    "discord": {
      "enabled": true,
      "config": {}
    }
  }
}

Then restart/kickstart the gateway. After that, logs confirmed Discord loaded and openclaw status --deep showed Discord ON / OK.

Expected behavior

If an update detects an enabled channel such as channels.discord.enabled = true, it should either:

  • migrate config by writing plugins.entries.discord = { "enabled": true, "config": {} }, or
  • load the channel plugin based on the enabled channel block, or
  • emit a loud doctor / status --deep warning that a configured channel has no loaded plugin.

Why this matters

This is silent user-facing channel loss. The package is installed, plugins list says enabled, and config still contains channels.discord, but the bot does not respond on Discord. The only clear diagnostic is the mismatch between plugins list, status --deep, and the gateway loaded-plugin line.

Reproducer

  1. Start from a pre-2026.5.18 install with channels.discord.enabled = true and no plugins.entries.discord entry.
  2. Run openclaw update --yes to 2026.5.18.
  3. Observe the updater installs @openclaw/discord.
  4. Restart gateway.
  5. Observe openclaw status --deep does not list Discord, while openclaw plugins list still reports Discord enabled.

Suggested fix

During update, for each configured enabled channel whose runtime now requires an external plugin entry, ensure plugins.entries.<id>.enabled = true exists before the update is considered complete.

Also consider adding a doctor warning for:

channels.<id>.enabled = true but plugins.entries.<id>.enabled is missing or false

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If an update detects an enabled channel such as channels.discord.enabled = true, it should either:

  • migrate config by writing plugins.entries.discord = { "enabled": true, "config": {} }, or
  • load the channel plugin based on the enabled channel block, or
  • emit a loud doctor / status --deep warning that a configured channel has no loaded plugin.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Bug: Discord channel silently disabled after 2026.5.18 update without plugin-entry migration [2 comments, 2 participants]