feat(plugins): narrow explicit provider loads from manifests by vincentkoc · Pull Request #65259 · openclaw/openclaw

vincentkoc · 2026-04-12T08:38:09Z

Summary

Problem: explicit providerRefs setup/runtime loads still relied on older manifest ownership helpers, so descriptor-first provider activation hints were not actually narrowing those paths.
Why it matters: provider-targeted setup/runtime flows could still over-load plugins, and explicit owner ids discovered from manifest activation/setup metadata could get dropped by the legacy providers.length > 0 filter.
What changed: provider runtime/setup loading now plans explicit provider owners from manifest activation metadata first, keeps legacy provider/CLI-backend ownership as fallback, and preserves explicit owner ids through the final load options.
What did NOT change (scope boundary): no new global activation snapshot model, no broad registry rewrite, no repo-wide manifest backfill.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related #
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: explicit provider targeting on setup/runtime paths still routed through legacy manifest ownership helpers instead of the new activation-planner seam.
Missing detection / guardrail: there was no focused test proving activation.onProviders or setup.providers owners survived all the way into provider load options.
Contributing context (if known): the CLI planning slice landed first, so provider-specific paths were still on the older ownership logic.

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/providers.test.ts
Scenario the test should lock in: explicit provider-targeted setup/runtime loads keep activation/setup-descriptor owners, while legacy CLI-backend ownership still works as fallback.
Why this is the smallest reliable guardrail: the regression lives in provider load planning before runtime execution, so a focused providers-runtime unit test catches it without booting the full plugin graph.
Existing test that already covers this (if any): none before this change.
If no new test is added, why not: N/A

User-visible / Behavior Changes

None.

Diagram (if applicable)

Before:
[providerRefs] -> [legacy ownership helper] -> [enabled/discovered provider filter] -> [activation/setup-only owner can be dropped]

After:
[providerRefs] -> [manifest activation planner] -> [legacy fallback if needed] -> [explicit owner ids preserved into load options]

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): No
Data access scope changed? (Yes/No): No
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: macOS
Runtime/container: local Node/pnpm worktree
Model/provider: N/A
Integration/channel (if any): plugin/provider load path
Relevant config (redacted): default local dev config

Steps

Add a plugin manifest owner that declares activation.onProviders or setup.providers for an explicit provider id without the older providers[] static metadata.
Resolve plugin providers with providerRefs on runtime or setup paths.
Inspect the final onlyPluginIds / activated config used for provider loading.

Expected

Explicit provider owners resolved from manifest metadata stay in the provider load options.
Legacy CLI-backend ownership still resolves when activation metadata is absent.

Actual

Fixed by this PR.

Evidence

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

Human Verification (required)

Verified scenarios: explicit runtime provider ownership via activation.onProviders; explicit setup provider ownership via setup.providers; legacy CLI-backend fallback via claude-cli; existing provider runtime tests still green.
Edge cases checked: explicit owner ids survive the legacy provider filter; setup and runtime paths both covered.
What you did not verify: full repo pnpm check; broad end-to-end plugin flows.

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: manifest activation metadata could over-target a plugin if its provider ownership is declared incorrectly.
- Mitigation: legacy fallback remains in place, and new focused tests lock the explicit-owner load behavior.

greptile-apps · 2026-04-12T08:43:53Z

Greptile Summary

This PR narrows explicit provider setup/runtime loads to use manifest activation metadata (activation.onProviders, setup.providers) as the primary ownership signal before falling back to legacy static providers[] and cliBackends ownership. The fix correctly handles the case where a plugin declares activation ownership without a matching static providers[] entry, which would previously cause the plugin to be silently dropped from setup/runtime load options.

Three focused tests lock in the new behavior across the runtime path (activation.onProviders), setup path (setup.providers), and legacy fallback (cliBackends).

Confidence Score: 5/5

Safe to merge — logic is correct, legacy fallback is preserved, and all three new code paths are test-covered.

The only finding is a P2 style suggestion to flatten a nested guard into a single compound condition; no correctness, data-integrity, or security issues were found.

No files require special attention.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/plugins/providers.runtime.ts
Line: 141-145

Comment:
**Nested guard can be flattened**

The double-`if` reads as two independent decisions, but the intent is a single compound condition: return early only when both `providerPluginIds` and `explicitOwnerPluginIds` are empty. A single `&&` guard makes the invariant easier to scan and avoids a misleading `if (0 === 0) { if (...) }` shape.

```suggestion
  if (providerPluginIds.length === 0 && base.explicitOwnerPluginIds.length === 0) {
    return undefined;
  }
```

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

_{Reviews (1): Last reviewed commit: "feat(plugins): narrow explicit provider ..." | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f69e89a5b3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3cb61f4055

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f547bed660

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-12T09:52:49Z

+  const runtimeRequestedPluginIds =
+    base.requestedPluginIds !== undefined
+      ? dedupeSortedPluginIds([...(params.onlyPluginIds ?? []), ...explicitOwnerPluginIds])
+      : undefined;


Keep explicit provider loads scoped when owner filter empties

When explicit providerRefs resolve owner plugins that are then filtered out (for example plugins.enabled=false, entries[id].enabled=false, or allowlist exclusion), this branch sets runtimeRequestedPluginIds to an empty array. That looks scoped, but loader normalization later converts [] to undefined (normalizeScopedPluginIds), so resolveRuntimePluginRegistry/loadOpenClawPlugins can treat the request as unscoped and load all enabled provider plugins instead of none. Fresh evidence versus earlier reports: the current code uses [], but src/plugins/loader.ts still collapses that to unscoped behavior.

Useful? React with 👍 / 👎.

…w#65259) * feat(plugins): narrow explicit provider loads from manifests * fix(plugins): preserve setup trust filtering for explicit owners * fix(plugins): respect runtime owner trust and disablement * fix(plugins): preserve provider owner policy bounds

feat(plugins): narrow explicit provider loads from manifests

f69e89a

vincentkoc self-assigned this Apr 12, 2026

openclaw-barnacle Bot added docs Improvements or additions to documentation size: S maintainer Maintainer-authored PR labels Apr 12, 2026

vincentkoc marked this pull request as ready for review April 12, 2026 08:38

This comment has been minimized.

Sign in to view

greptile-apps Bot reviewed Apr 12, 2026

View reviewed changes

Comment thread src/plugins/providers.runtime.ts Outdated

chatgpt-codex-connector Bot reviewed Apr 12, 2026

View reviewed changes

Comment thread src/plugins/providers.runtime.ts Outdated

fix(plugins): preserve setup trust filtering for explicit owners

95dadec

openclaw-barnacle Bot added size: M and removed size: S labels Apr 12, 2026

fix(plugins): respect runtime owner trust and disablement

3cb61f4

openclaw-barnacle Bot added size: L and removed size: M labels Apr 12, 2026

chatgpt-codex-connector Bot reviewed Apr 12, 2026

View reviewed changes

Comment thread src/plugins/providers.runtime.ts Outdated

fix(plugins): preserve provider owner policy bounds

f547bed

vincentkoc merged commit 12db6df into main Apr 12, 2026
41 of 42 checks passed

vincentkoc deleted the feat/ocplugins-provider-runtime-planning branch April 12, 2026 09:52

chatgpt-codex-connector Bot reviewed Apr 12, 2026

View reviewed changes

github-actions Bot mentioned this pull request Apr 12, 2026

📡 Upstream Digest — 2026-04-12 10:31 UTC curtismercier/openclaw-mods#548

Open

vincentkoc mentioned this pull request Apr 12, 2026

fix(plugins): centralize explicit plugin scope handling #65298

Merged

25 tasks

ttomiczek mentioned this pull request Apr 14, 2026

memory-core: dreaming cron reports 'cron service unavailable' — regression from 4.12 plugin loading changes #66388

Closed

martingarramon mentioned this pull request Apr 14, 2026

[Bug]: memory-core dreaming cron reconciliation can report "cron service unavailable" even when gateway cron is running #65834

Closed

steipete mentioned this pull request Apr 25, 2026

fix(cli): skip full plugin preload for channels login/logout when --channel is explicit #59713

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(plugins): narrow explicit provider loads from manifests#65259

feat(plugins): narrow explicit provider loads from manifests#65259
vincentkoc merged 4 commits intomainfrom
feat/ocplugins-provider-runtime-planning

vincentkoc commented Apr 12, 2026

Uh oh!

This comment has been minimized.

greptile-apps Bot commented Apr 12, 2026

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Apr 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

vincentkoc commented Apr 12, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

This comment has been minimized.

greptile-apps Bot commented Apr 12, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Apr 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant