Summary

• Problem: direct npm installs of official-looking packages could still reach the trusted install scanner path by package name instead of by OpenClaw-owned install provenance.
• Why it matters: typing an npm package name should not bypass launch-code scanning; only catalog/onboarding/doctor paths that OpenClaw owns should grant that trust bit.
• What changed: removed the name-based official npm trust helper, plumbed explicit trustedSourceLinkedOfficialInstall through CLI, onboarding, doctor, channel catalog, and provider setup paths, and kept direct npm: semantics untrusted.
• What did NOT change (scope boundary): no npm pinning requirement or release-process rewrite; integrity drift checks remain optional where catalog metadata has a pin.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related security: require pinned spec + integrity for official npm plugin trust #76455
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: installPluginFromNpmSpec could infer official trust from npm package name + plugin id, independent of the caller path.
• Missing detection / guardrail: direct npm specs with dangerous launch code were covered as trusted official installs instead of being covered as untrusted direct npm installs.
• Contributing context (if known): security: require pinned spec + integrity for official npm plugin trust #76455 identified the trust-bypass shape; this reworks the fix around provenance instead of version/integrity pinning.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/install.npm-spec.test.ts, src/cli/plugins-cli.install.test.ts, src/commands/onboarding-plugin-install.test.ts, src/commands/doctor/shared/missing-configured-plugin-install.test.ts, src/channels/plugins/contracts/channel-catalog.contract.test.ts.
• Scenario the test should lock in: direct official npm package names are scanned normally, while OpenClaw-owned catalog/onboarding/doctor installs pass the explicit trust bit.
• Why this is the smallest reliable guardrail: it covers the scanner decision and every caller that intentionally grants provenance trust.
• Existing test that already covers this (if any): existing trusted source-linked archive/package scanner tests still cover the scanner-level allow path.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Direct npm installs of official packages no longer get the trusted scanner bypass just because the package name looks official. Official catalog, onboarding, and doctor installs continue to work through explicit OpenClaw-owned provenance.

Diagram (if applicable)

Before:
openclaw plugins install npm:@openclaw/codex -> package-name helper -> trusted scanner path

After:
openclaw plugins install npm:@openclaw/codex -> normal scanner path
openclaw plugins install codex/catalog/onboarding/doctor -> OpenClaw provenance bit -> trusted scanner path

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) Yes
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: plugin install launch-code scanner trust is narrowed to OpenClaw-owned install paths; direct npm installs receive normal scanner scrutiny.

Repro + Verification

Environment

• OS: macOS local targeted tests, Crabbox AWS Linux changed gate
• Runtime/container: Node 22 / pnpm
• Model/provider: N/A
• Integration/channel (if any): plugin install, channel catalog, provider setup, onboarding, doctor
• Relevant config (redacted): N/A

Steps

1. Install an official-looking npm package directly with dangerous launch code.
2. Install the same package through an OpenClaw-owned catalog/onboarding/doctor path.
3. Run the changed gate remotely.

Expected

• Direct npm install is scanned normally and blocked when launch code is dangerous.
• OpenClaw-owned install paths pass the explicit trusted provenance flag.

Actual

• Matches expected.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • pnpm test:serial src/plugins/install.npm-spec.test.ts src/cli/plugins-cli.install.test.ts src/commands/onboarding-plugin-install.test.ts src/commands/doctor/shared/missing-configured-plugin-install.test.ts src/channels/plugins/contracts/channel-catalog.contract.test.ts src/commands/auth-choice.apply.plugin-provider.test.ts
  • pnpm test:serial src/plugins/install.test.ts src/plugins/provider-auth-choices.test.ts src/plugins/provider-install-catalog.test.ts src/commands/channel-setup/plugin-install.test.ts
  • pnpm exec oxfmt --check --threads=1 ...
  • node scripts/run-oxlint.mjs ...
  • Crabbox cbx_6157440c9bbe / run_cbd813956eed: pnpm check:changed passed
• Edge cases checked: direct explicit npm: official id does not get provenance trust; hook fallback still gets catalog integrity; third-party WeCom catalog mock does not get official trust unless it comes from official external catalog.
• What you did not verify: live npm or ClawHub artifact download.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: an official install path forgets to pass provenance and gets scanned as an ordinary npm install.
  • Mitigation: caller coverage for CLI catalog aliases, onboarding, doctor repair, channel catalog contracts, and provider setup.