When a user's config has a stale `channels.<id>` entry (e.g. `appId`
or tokens left over from an earlier install) and the plugin is no
longer on disk -- for instance because the externalized npm package
was uninstalled or pruned during an upgrade -- `handleChannelChoice`
used to dead-end with "<channel> plugin not available." and leave
onboard stuck until the user manually deleted the config entry and
re-ran the CLI.
Two discovery paths are affected:
1. The `installedCatalogEntry` branch: when
`loadScopedChannelPlugin` returns null but the catalog entry still
carries `install.npmSpec`, fall back to
`ensureChannelSetupPluginInstalled` with the same entry so onboard
can reinstall the plugin from the official catalog.
2. The bundled-enable `else` branch: with a non-empty
`channels.<id>` record, `isStaticallyChannelConfigured` drops the
channel from `installableCatalogEntries`; if the plugin is also
missing on disk (so it never enters `manifestInstalledIds`), both
discovery buckets come back empty and the channel falls through to
`enableBundledPluginForSetup`. Before delegating to that bundled
path, consult the trusted catalog via
`getTrustedChannelPluginCatalogEntry` and, if an `install.npmSpec`
is available, drive the same catalog install flow used by a fresh
pick of the channel.
Both new fallbacks re-apply the `resolveConfigDisabledHint` guard
that `enableBundledPluginForSetup` has always enforced, so an
operator-disabled channel (`plugins.entries.<id>.enabled === false`
or explicit `channels.<id>.enabled === false`) with a stale config
entry cannot be silently reinstalled or re-enabled through the
catalog path.
Both branches also keep their previous behavior when no catalog npm
spec is available (e.g. purely bundled channels), so this change is
a superset of the old flow rather than a replacement.
Affects all externalized channel plugins listed in the core
package's `files` exclusion (qqbot, bluebubbles, discord, whatsapp,
line, msteams, feishu, googlechat, nostr, zalo, zalouser,
synology-chat, tlon, twitch, and similar).
Remove stale managed-root openclaw manifests, locks, hidden locks, and installed copies before npm plugin installs.
Relink plugin-local openclaw peer symlinks after shared-root npm install, rollback, update, and uninstall mutations so SDK-using plugins keep resolving openclaw/plugin-sdk/*.
Force safe npm commands out of inherited legacy/strict peer-dependency modes.
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
Co-authored-by: Patrick Erichsen <patrick.a.erichsen@gmail.com>
