Summary

What problem does this PR solve?

Root cause: the official external plugin recovery resolver used the raw install spec as the identity key, so the versioned npm spec @openclaw/discord@2026.5.22 did not resolve to the catalog source identity @openclaw/discord. That resolver miss caused the invalid-config recovery path to preserve the stale plugins.load.paths entry, and config validation rejected the write after the install action.

Why does this matter now?

NemoClaw onboarding can select Discord, then the image build runs the versioned Discord install command from the generated build script. When the previous Discord plugin path is missing, the build cannot finish even though this is exactly the kind of stale plugin state the recovery install path is meant to repair.

What is the intended outcome?

Fix classification: root-cause fix. The installer now maps versioned official npm specs back to their package name for recovery metadata, and the recovery config removes only validation-reported missing plugin load paths before persisting the repaired install state.

What is intentionally out of scope?

What did NOT change: this PR does not change Discord runtime auth, live bot connection behavior, marketplace override semantics, plugin schema defaults, migration files, unrelated plugin load paths, or non-recovery install behavior.

What does success look like?

A stale Discord plugin config that previously blocked plugins install @openclaw/discord@2026.5.22 now installs successfully and validates afterward.

What should reviewers focus on?

Why this is root-cause fix: the source boundary is the install-spec resolver and official external plugin catalog mapping, not the Docker build script. The patch parses the npm spec to its package identity before matching catalog recovery metadata, then applies the config validation invariant at persistence time by removing only the load path that validation proved missing. This fixes the resolver/source-of-truth mismatch and the invalid config write source, instead of adding a Discord-only fallback or bypassing config validation.

Patch quality notes: the helper returns null for non-plugins.load.paths issues and for messages without the plugin path not found: marker so unrelated validation errors cannot drive cleanup. The as unknown as OpenClawConfig cast is limited to the existing test style for partial config snapshots. Patch warning/default-return smell is not masking a runtime failure; it is a parser guard that keeps cleanup opt-in to the validation issue shape.

Architecture / source-of-truth check: the source of truth for official external plugin identity remains the official external plugin catalog, and the source of truth for removable stale load paths is the config validation diagnostic. Related open PR / same-contract scan from init found no competing linked PR for this issue. Public contract surface is config compatibility only: existing invalid recovery requests become repairable, while other invalid configs still fail through the same guard.

Linked context

Which issue does this close?

Closes #90333

Which issues, PRs, or discussions are related?

Related PR / competition scan: daily-fix init found no linked open PR for this issue.

Was this requested by a maintainer or owner?

No direct maintainer request beyond the linked issue report.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: openclaw plugins install @openclaw/discord@2026.5.22 can recover a stale Discord install even when the existing config has channels.discord and a missing plugins.load.paths entry.

• Real environment tested: local OpenClaw CLI with an isolated temporary OPENCLAW_HOME and config that reproduced the stale Discord plugin path failure.

• Exact steps or command run after this patch: create a config containing a stale Discord npm install, channels.discord, and plugins.load.paths: ["/missing/discord"]; then run pnpm dev plugins install @openclaw/discord@2026.5.22 followed by pnpm dev config validate.

• Evidence after fix (terminal capture, redacted):

  $ node scripts/run-node.mjs plugins install @openclaw/discord@2026.5.22
  OpenClaw config is invalid
  Problem:
    - plugins.load.paths: plugin: plugin path not found: /missing/discord
  
  Fix: openclaw doctor --fix
  Inspect: openclaw config validate
  Status, health, logs, tasks list/audit, and doctor commands still run with invalid config.
  Using bundled plugin "discord" from <repo>/dist/extensions/discord for npm install spec "@openclaw/discord@2026.5.22" because this plugin ships with the current OpenClaw build. To force an external npm override, use npm:@openclaw/discord@2026.5.22.
  Installed plugin: discord
  Restart the gateway to load plugins.
  
  $ node scripts/run-node.mjs config validate
  Config valid: <temp-config>/config.json5
  

• Observed result after fix: the versioned Discord install completes and the same config validates successfully afterward.

• What was not tested: a live Discord bot connection or a full NemoClaw Docker image build.

• Proof limitations or environment constraints: the proof focuses on the failing OpenClaw CLI recovery command from the image build log; no Discord token was needed or used for this config recovery path.

• Before evidence (optional but encouraged): the new regression test failed before the fix because /gone remained in plugins.load.paths after loadConfigForInstall, which would make the install write fail validation.

Tests and validation

Which commands did you run?

Target test file: src/cli/plugins-install-config.test.ts and src/cli/program/preaction.test.ts.

• pnpm exec vitest run src/cli/plugins-install-config.test.ts src/cli/program/preaction.test.ts
• pnpm dev plugins install @openclaw/discord@2026.5.22 with stale Discord config, then pnpm dev config validate
• pnpm run deps:shrinkwrap:changed:check
• pnpm run lint -- src/cli/plugin-install-config-policy.ts src/cli/plugins-install-command.ts src/cli/plugins-install-config.test.ts src/cli/program/preaction.test.ts

What regression coverage was added or updated?

Scenario locked in: versioned official npm specs inherit Discord invalid-config recovery metadata, the CLI pre-action guard allows invalid config for plugins install @openclaw/discord@2026.5.22, and recovery install config removes validation-reported missing plugins.load.paths entries before persistence.

What failed before this fix, if known?

Why this is the smallest reliable guardrail: the focused config test failed before the implementation because the missing path stayed in plugins.load.paths; the command proof exercises the same install command shape from the issue and confirms the repaired config validates after install.

If no test was added, why not?

Not applicable; regression tests were added for the resolver/pre-action path and the config cleanup path.

Known validation note: pnpm run check was also run; all preflight guards shown in the output passed except the repository-wide npm shrinkwrap guard, which reported npm-shrinkwrap.json is stale. Run pnpm deps:shrinkwrap:generate. No package or lockfile changes are part of this PR, and deps:shrinkwrap:changed:check passed.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes.

Did config, environment, or migration behavior change? (Yes/No)

Yes.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No.

What is the highest-risk area?

Risk labels considered: config compatibility and plugin install availability. The install command now mutates invalid recovery config by dropping missing plugin load paths reported by validation.

How is that risk mitigated?

Why acceptable: the recovery path is still gated to official plugin install requests that opt into invalid-config recovery; cleanup only uses plugins.load.paths validation issues whose message includes plugin path not found:; unrelated load paths are preserved; and non-recovery installs still fail with the existing invalid-config error.

Current review state

What is the next action?

Maintainer-ready confidence: high. Next action is remote CI and maintainer review after PR creation.

What is still waiting on author, maintainer, CI, or external proof?

Waiting on remote CI after PR creation. No author-side follow-up is known from local validation.

Which bot or reviewer comments were addressed?

No bot or reviewer comments yet; this is a new issue fix.