Summary

• follow up on fix(plugins): block untrusted workspace setup-only channel loads #86953's workspace-only setup trust fix by extending the same trusted-catalog fallback logic to local config / global channel plugins discovered through plugins.load.paths or linked installs
• prove the regression on current code with the blackbox plugin-trust harness: clean main blocks trusted plugins.load.paths setup because the catalog never sees that channel, while this branch reaches the loader and passes all four trust cases
• keep the setup trust rule origin-aware: reject untrusted local shadows by { pluginId, origin }, then fall back to a safe bundled/non-local copy instead of suppressing all copies of the same plugin id
• fix the .dts build break in src/commands/channel-setup/trusted-catalog.ts, which was failing fresh pnpm build:plugin-sdk:dts / Docker image builds even when local incremental caches hid it
• add main-repo L4 coverage plus a focused Docker/package L6 manual proof script for the local channel plugin trust boundary

Change Type

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

Scope

• Integrations
• API / contracts
• UI / DX
• CI / infra
• Gateway / orchestration
• Auth / tokens
• Memory / storage

Linked Issue / PR

• Follow-up to merged fix(plugins): block untrusted workspace setup-only channel loads #86953 (fix(plugins): block untrusted workspace setup-only channel loads)
• Context and autoreview notes: my_docs/my_docs/04-cases/2026-04-10-channel-workspace-shadow-case/pr-86953-autoreview-follow-up.zh.md
• This PR exists because fix(plugins): block untrusted workspace setup-only channel loads #86953 fixed the workspace trust boundary, but the same local-code trust question still applied to plugins.load.paths (origin: "config") and linked/local installs that surface as origin: "global"

Problem Statement

#86953 established the product rule that untrusted local channel plugins should not get imported during setup-only channel flows. That landed for workspace-origin plugins.

The remaining gap was the broader local-origin surface:

• plugins.load.paths channel plugins appear as origin: "config"
• linked / managed local installs can appear as origin: "global"

Those are still local code from the operator's point of view. If setup hardening only keys on origin === "workspace", the trust boundary is inconsistent: one class of local plugin is blocked before import, while other local shadows can still win channel catalog resolution or suppress a safe bundled fallback.

This branch also had a separate concrete defect in fresh builds: src/commands/channel-setup/trusted-catalog.ts failed declaration generation, so Docker image builds died in build:plugin-sdk:dts even though local incremental caches could mask the problem.

The fresh-build failure was:

src/commands/channel-setup/trusted-catalog.ts(82,3): error TS2344:
Type '"excludeOrigins" | "excludePluginRefs"' does not satisfy the constraint 'never'.
src/commands/channel-setup/trusted-catalog.ts(97,3): error TS2322:
Type '{ excludeOrigins?: (PluginOrigin | undefined)[] | undefined; ... }'
is not assignable to type 'Pick<CatalogOptions | undefined, "excludeOrigins" | "excludePluginRefs">'.
src/commands/channel-setup/trusted-catalog.ts(113,61): error TS2345:
Argument of type '{ ... excludeOrigins: unknown; excludePluginRefs: unknown; }'
is not assignable to parameter of type 'CatalogOptions'.

Blackbox Proof

Harness:

• e2e repo: sibling openclaw-e2e-go
• spec: specs/plugintrust/local_origin_followup_test.go
• probe: scripts/docker/test-plugintrust-local-origin.sh
• fixtures: scripts/fixtures/plugintrust/{workspace-shadow,load-paths-shadow}/
• command: OPENCLAW_E2E_TARGET_REPO=<openclaw checkout> go test ./specs/plugintrust -v

The harness bakes a fresh OpenClaw image from source, then asserts only on marker files written by fixture plugins:

• PLUGINTRUST_SETUP_IMPORT_MARKER: module top-level import happened
• PLUGINTRUST_SETUP_REGISTER_MARKER: setup hook actually ran

Clean main (a4196a44454f) behavior:

• Case 1 workspace + untrusted: PASS, trust gate blocks the untrusted workspace plugin
• Case 2 workspace + plugins.allow: PASS, trusted workspace plugin loads
• Case 3 load-paths + untrusted: PASS as probe-only, marker absent because catalog rejects Unknown channel e2e-load-paths before loader
• Case 4 load-paths + plugins.allow: FAIL, same Unknown channel e2e-load-paths; trusted load-path plugin is still invisible to the catalog on main

This branch behavior from the previously built fresh image:

• Case 1: PASS, untrusted workspace shadow not loaded
• Case 2: PASS, trusted workspace shadow loaded
• Case 3: PASS, load-path probe reached and recorded
• Case 4: PASS, trusted load-path plugin loaded

That is the direct before/after proof for the regression this PR fixes: on main, trusted plugins.load.paths channels never reach setup because the catalog cannot resolve them; on this branch, the same scenario resolves and loads correctly while the untrusted cases still stay blocked.

What Changed

1. Thread extraPaths through channel catalog resolution so trusted channel setup/add flows can actually see channel plugins discovered from plugins.load.paths.
2. Make fallback exclusion origin-aware with excludePluginRefs: [{ pluginId, origin }], so rejecting an untrusted local shadow only skips that exact local candidate and still allows a bundled copy of the same channel/plugin id to win.
3. Keep setup discovery lenient for display-only cases: if an untrusted local entry has no trusted fallback, it stays visible in the setup discovery bucket rather than disappearing from the UI.
4. Fix the TypeScript declaration-build typing in trusted-catalog.ts by replacing the unstable Pick<Parameters<...>[1], ...> shape with an explicit local exclusions type and explicit local-origin narrowing.
5. Add src/commands/channels.add.trust.e2e.test.ts as a main-repo L4 E2E regression for the real channels add CLI path.
6. Add bash scripts/e2e/channel-plugin-trust-docker.sh as a focused Docker/package L6 manual proof script for the plugins.load.paths trust boundary.

Why This Is The Right Follow-up To #86953

#86953 already proved the core trust model: local untrusted channel plugin code must not execute in setup-only flows. This PR does not redefine that model; it applies the same invariant consistently to the remaining local origins the earlier PR intentionally left as a follow-up hardening item.

The pr-86953-autoreview-follow-up.zh.md note called out exactly this direction: stop hardcoding one origin name and move the loader/catalog gate toward a unified local trust decision. This PR stays within that scope and keeps the current product behavior for trusted plugins:

• explicitly trusted / allowlisted local plugins still resolve
• bundled entries still act as the safe fallback when a local shadow is not trusted
• discovery UI can still show installable local-only candidates without treating them as executable

Verification

• pnpm build:plugin-sdk:dts
• pnpm test src/commands/channel-setup/trusted-catalog.test.ts -- --reporter=verbose
• pnpm build
• pnpm test src/commands/channels.add.trust.e2e.test.ts -- --reporter=verbose
• bash scripts/e2e/channel-plugin-trust-docker.sh
• git diff --check
• env npm_config_registry=https://registry.npmjs.org/ node scripts/generate-npm-shrinkwrap.mjs --check
• Blackbox harness context above from sibling openclaw-e2e-go

Evidence

• Fresh pnpm build:plugin-sdk:dts now passes after the trusted-catalog.ts type fix; this was the blocker for Docker image rebuilds.
• Focused Vitest passed: 10/10 in src/commands/channel-setup/trusted-catalog.test.ts.
• pnpm build passes after the declaration-build fix.
• Main-repo L4 E2E passed: src/commands/channels.add.trust.e2e.test.ts covers workspace/load-paths x trusted/untrusted, 4/4 passing through the real openclaw channels add CLI path.
• New L6 Docker/package manual proof passed locally: bash scripts/e2e/channel-plugin-trust-docker.sh built the package artifacts, packed/checked the OpenClaw tarball, installed it into the functional Docker image, then verified plugins.load.paths untrusted blocks setup entry execution and plugins.allow permits setup entry execution.
• Root npm-shrinkwrap.json was regenerated/check-verified with https://registry.npmjs.org/; no local mirror URLs are present.
• pnpm check:changed could not complete locally because the installed Crabbox binary is 0.15.0 while current Testbox delegation requires Crabbox >=0.22.0. Running the child command directly reached existing shrinkwrap guard behavior for changed plugin packages; no test/lint/type failure was observed before that guard.