Module-level constant preferred

KNOWN_CHANNEL_ID_SET is derived entirely from CHANNEL_IDS, which is a compile-time constant. Rebuilding the Set inside the function on every call to validateConfigObjectWithPluginsBase is harmless (it's a tiny array), but hoisting it to module scope makes the intent clearer and avoids unnecessary allocations:

…or better yet, declare it at module scope alongside LEGACY_REMOVED_PLUGIN_IDS:

const KNOWN_CHANNEL_ID_SET: ReadonlySet<string> = new Set(CHANNEL_IDS as readonly string[]);

Then remove the local declaration and reference the module-level constant inside the function.

This is a comment left during a code review.
Path: src/config/validation.ts
Line: 527

Comment:
**Module-level constant preferred**

`KNOWN_CHANNEL_ID_SET` is derived entirely from `CHANNEL_IDS`, which is a compile-time constant. Rebuilding the `Set` inside the function on every call to `validateConfigObjectWithPluginsBase` is harmless (it's a tiny array), but hoisting it to module scope makes the intent clearer and avoids unnecessary allocations:

```suggestion
  const CHANNEL_IDS_SET: ReadonlySet<string> = new Set(CHANNEL_IDS);
```

…or better yet, declare it at module scope alongside `LEGACY_REMOVED_PLUGIN_IDS`:

```ts
const KNOWN_CHANNEL_ID_SET: ReadonlySet<string> = new Set(CHANNEL_IDS as readonly string[]);
```

Then remove the local declaration and reference the module-level constant inside the function.

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Test doesn't assert res.ok === true

The comment says "Config should still be valid (warnOnly path)" but the assertion is never made. If a future change accidentally starts emitting issues instead of warnings (making res.ok === false), this test would still pass because res.warnings is present on both result shapes. Adding an explicit ok assertion closes that gap:

This is a comment left during a code review.
Path: src/config/config.plugin-validation.test.ts
Line: 538

Comment:
**Test doesn't assert `res.ok === true`**

The comment says "Config should still be valid (warnOnly path)" but the assertion is never made. If a future change accidentally starts emitting issues instead of warnings (making `res.ok === false`), this test would still pass because `res.warnings` is present on both result shapes. Adding an explicit `ok` assertion closes that gap:

```suggestion
    expect(res.ok).toBe(true);
    // Config should still be valid (warnOnly path) but with an install hint.
    expect(res.warnings).toContainEqual({
```

How can I resolve this? If you propose a fix, please make it concise.

Include extension-backed optional channels in this install-hint check

Because KNOWN_CHANNEL_ID_SET is built only from CHANNEL_IDS, this branch only recognizes the built-in chat IDs from src/channels/ids.ts:4-14. Most optional bundled channel plugins that were moved out of the default build (matrix, msteams, nostr, tlon, twitch, zalouser) are extension channels listed in scripts/lib/optional-bundled-clusters.mjs:1-14, and their config still lives under channels.* (src/config/zod-schema.providers.ts:25-46). Those upgrades will continue to fall through to the old unknown channel id/stale-entry behavior instead of getting the new install guidance, so this fix only covers a small subset of the affected channels.

Useful? React with 👍 / 👎.

Use the declared npm install spec in the warning

This message hard-codes openclaw plugins install ${pluginId}, but the official install surface for repo-owned channel plugins is the package's declared install.npmSpec (for example @openclaw/whatsapp in extensions/whatsapp/package.json:36-40), and ensureChannelSetupPluginInstalled installs that exact spec in src/commands/channel-setup/plugin-install.ts:185-199. For channels whose package name is scoped, users following this new warning on stable/beta builds can still fail to install the plugin or resolve a different package than the one OpenClaw expects.

Useful? React with 👍 / 👎.

Downgrade missing allowlisted optional channels to install hints

When a built-in channel becomes optional-bundled (for example googlechat in scripts/lib/optional-bundled-clusters.mjs:8-19), upgrades with a non-empty plugins.allow still fail validation. enablePluginInConfig appends built-in channel IDs to plugins.allow whenever an allowlist exists (src/plugins/enable.ts:21-22, src/plugins/enable.test.ts:43-52), but this new branch only runs on the warnOnly path used for plugins.entries.*; the later plugins.allow check still emits a hard plugin not found error. That leaves existing allowlisted channel installs unable to start instead of getting the migration guidance this patch is supposed to add.

Useful? React with 👍 / 👎.

Emit the install hint for channel-only configs as well

This hint is only reached after an unknown plugin ID is found under plugins.entries, but bundled chat channels can be enabled from channels.<id>.enabled=true alone (src/plugins/config-state.test.ts:171-176, src/plugins/loader.test.ts:753-766). For optional-bundled built-ins like googlechat (scripts/lib/optional-bundled-clusters.mjs:8-19), a config that only sets channels.googlechat.enabled=true never creates plugins.entries.googlechat, so validation now succeeds with no warning at all even though the channel plugin is absent and will not load.

Useful? React with 👍 / 👎.

Keep WhatsApp helper barrels out of openclaw.extensions

openclaw.extensions is consumed as the set of loadable plugin entrypoints in src/plugins/discovery.ts:584-603 and src/plugins/discovery.ts:715-730, not as a generic “files to publish” list. Once this array has more than one entry, deriveIdHint() switches the primary candidate to whatsapp/index (src/plugins/discovery.ts:339-365), which src/plugins/manifest-registry.ts:388-394 immediately reports as a plugin id mismatch for manifest id whatsapp. That warning is then surfaced during config validation and normal gateway startup (src/config/validation.ts:411-418, src/gateway/server-plugins.ts:429-444), so this change makes every bundled/workspace WhatsApp load look broken even when the plugin is fine.

Useful? React with 👍 / 👎.

Extend the install hint to plugin-entry-enabled channel configs

This new branch only looks at channels.<id> before deciding to show the install guidance. An explicit plugins.entries.<id>.enabled = true is also a supported way to enable a channel plugin — resolveEnableState() treats entry.enabled === true as enabled even without any channels.<id> section (src/plugins/config-state.ts:286-301) — so those plugin-centric configs still fall through to the old stale config entry ignored warning. In practice, upgrades that enable a channel through plugins.entries.whatsapp will still get told to remove the config instead of being shown how to install the missing plugin.

Useful? React with 👍 / 👎.

Build the runtime shims instead of copying raw .ts files

This postbuild only copies top-level shim sources into dist/extensions/<plugin>, but the shims it is trying to rescue still immediately re-export ./src/*.js (for example extensions/whatsapp/runtime-api.ts and light-runtime-api.ts). tsdown.config.ts only emits declared openclaw.extensions/setupEntry entrypoints, so no dist/extensions/whatsapp/src/* tree is generated alongside these copied files. In packaged installs, src/plugins/runtime/runtime-whatsapp-boundary.ts resolves dist/extensions/whatsapp/runtime-api.ts, Jiti has no sibling sources to rewrite against, and the WhatsApp runtime still fails to load.

Useful? React with 👍 / 👎.

Keep ACPX optional until its bundled dependency is staged

Removing acpx from optionalBundledClusters makes every default build claim ACPX is bundled, but scripts/stage-bundled-plugin-runtime-deps.mjs only installs bundled plugin dependencies when openclaw.bundle.stageRuntimeDependencies === true, and extensions/acpx/package.json does not opt in. That means the default package still ships without dist/extensions/acpx/node_modules/.bin/acpx, so resolveAcpxPluginConfig() falls back to a runtime npm install [email protected]; on offline or registry-restricted hosts the newly bundled ACP backend still comes up broken.

Useful? React with 👍 / 👎.