When users put a runtime command name like "dreaming" into `plugins.allow`,
validation now explains that it is a command provided by a specific plugin
(e.g. "memory-core") and suggests using the plugin id instead, rather than
the generic "plugin not found" warning that previously created a circular
trap with the CLI error message.
Similarly, running `openclaw dreaming` from the CLI now explains that
`/dreaming` is a runtime slash command (not a CLI command) and points users
to `openclaw memory` for CLI operations or `/dreaming` in a chat session.
Fixes two related UX problems:
1. `plugins.allow: ["dreaming"]` → validation warned "plugin not found"
2. `openclaw dreaming status` → CLI said "add dreaming to plugins.allow"
(which then triggered problem 1)
Root cause: "dreaming" is a slash command registered by the memory-core
plugin via `api.registerCommand()`, not a standalone plugin or CLI command.
schema.ts and validation.ts imported CHANNEL_IDS from channels/registry.js,
which re-exports from channels/ids.js but also imports plugins/runtime.js.
When the bundler resolves this dependency graph, the re-exported CHANNEL_IDS
can be undefined at the point config/validation.ts evaluates (temporal dead
zone), causing 'CHANNEL_IDS is not iterable' on startup.
Fix: import CHANNEL_IDS directly from channels/ids.js (the leaf module with
zero heavy dependencies) and normalizeChatChannelId from channels/chat-meta.js.
Fixes#48832
Co-authored-by: Brad Groux <bradgroux@users.noreply.github.com>
* feat(plugins): support multi-kind plugins for dual slot ownership
* fix: address review feedback on multi-kind plugin support
- Use sorted normalizeKinds() for kind-mismatch comparison in loader.ts
(fixes order-sensitive JSON.stringify for arrays)
- Derive slot-to-kind reverse mapping from SLOT_BY_KIND in slots.ts
(removes hardcoded ternary that would break for future slot types)
- Use shared hasKind() helper in config-state.ts instead of inline logic
* fix: don't disable dual-kind plugin that still owns another slot
When a new plugin takes over one slot, a dual-kind plugin that still
owns the other slot must not be disabled — otherwise context engine
resolution fails at runtime.
* fix: exempt dual-kind plugins from memory slot disablement
A plugin with kind: ["memory", "context-engine"] must stay enabled even
when it loses the memory slot, so its context engine role can still load.
* fix: address remaining review feedback
- Pass manifest kind (not hardcoded "memory") in early memory gating
- Extract kindsEqual() helper for DRY kind comparison in loader.ts
- Narrow slotKeyForPluginKind back to single PluginKind with JSDoc
- Reject empty array in parsePluginKind
- Add kindsEqual tests
* fix: use toSorted() instead of sort() per lint rules
* plugins: include default slot ownership in disable checks and gate dual-kind memory registration
- Added a test to ensure no warnings for legacy Brave config when bundled web search allowlist compatibility is applied.
- Updated validation logic to incorporate compatibility configuration for bundled web search plugins.
- Refactored the ensureRegistry function to utilize the new compatibility handling.
Prevent gateway startup failures when plugins.entries contains stale or removed plugin ids by downgrading unknown entry keys from validation errors to warnings.
Made-with: Cursor
(cherry picked from commit 34ef28cf63)
Land #25538 by @chilu18 to keep legacy google-antigravity-auth config entries non-fatal after removal (see #25862).
Co-authored-by: chilu18 <chilu.machona@icloud.com>
The hand-written config validator rejects `channels.modelByChannel` as
"unknown channel id: modelByChannel" even though the Zod schema, TypeScript
types, runtime code, and CLI docs all treat it as valid. The `defaults`
meta-key was already whitelisted but `modelByChannel` was missed when
the feature was added in 2026.2.21.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
