* fix(plugins): filter .d.mts and .d.cts declaration files in extension discovery
isExtensionFile only checked for .d.ts but not .d.mts or .d.cts.
path.extname('.d.mts') returns '.mts' so these declaration files
passed through all checks and were treated as valid plugin entries.
Replaced the single .d.ts check with a regex covering all TS
declaration file variants.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix: update d.mts test to use distinct filenames so it fails on old code
---------
Co-authored-by: Claude <noreply@anthropic.com>
* fix(plugins): enhance plugin API compatibility diagnostic messages with troubleshooting guidance
Improve the diagnostic messages in shouldSkipIncompatiblePackagePluginApi to
include actionable troubleshooting hints when plugin discovery is skipped due
to version mismatches or invalid metadata.
Related to #93908
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(plugins): align compatibility diagnostics
Extend the discovery guidance to the manifest-registry load path and assert the exact remediation text.\n\nCo-authored-by: 杨爱文 <yang.aiwen@xydigit.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(plugins): discover config load.paths plugins when index has entries
Installing a managed npm plugin populates the persisted plugin index.
Once the index has entries (index.plugins.length > 0),
loadPluginManifestRegistryForInstalledIndex is used instead of the
full discovery path. This path only processes plugins that already
exist in the index — if workspace plugins from config plugins.load.paths
are missing from the index, they are silently dropped from the manifest
registry, producing 'plugin not found (stale config entry ignored)'
warnings on gateway startup and in CLI commands.
Fix: after converting index records to plugin candidates, also
discover plugins from config plugins.load.paths and merge any
candidates that are not already represented in the index-based
list. This ensures config-origin workspace plugins are always
included in the manifest registry regardless of index completeness.
Fixes#99185
* fix(plugins): address clawsweeper review — config-only scope, pluginId scoping, regression tests
- P1: Limit extra discovery scope to config-origin candidates only
(filter by origin === 'config') instead of full discoverOpenClawPlugins
- P2: Preserve pluginId scoping for load-path candidates
(filter extra candidates by pluginIdSet when present)
- Add 3 regression tests: load.paths discovery, empty-load no-op,
pluginId scoping preservation
- Add L2 real behavior proof with direct function call evidence
🦞 diamond lobster: L2 evidence (real function call + objects)
Ref. https://github.com/openclaw/openclaw/pull/99196
* fix(plugins): replace discoverOpenClawPlugins with config-only discoverFromConfigPaths
P1: The installed-index fallback previously called discoverOpenClawPlugins,
which scans bundled/global/workspace roots and returns their diagnostics.
This allowed unrelated shared-root diagnostics to leak into the
installed-index config validation surface.
Replace it with discoverFromConfigPaths — a new helper that scans only
the user-configured plugins.load.paths entries via discoverFromPath
directly, producing zero bundled/global candidates or diagnostics.
P2: pluginId scoping is preserved for load-path candidates.
Added discoverFromConfigPaths to src/plugins/discovery.ts to keep the
config-only discovery path reusable and explicit.
🦞 diamond lobster: L2 evidence (terminal output from real dev build)
Ref. https://github.com/openclaw/openclaw/pull/99196
* fix(plugins): preserve bundled-load-path alias filtering in discoverFromConfigPaths
P2: The new discoverFromConfigPaths helper (added in Round 1 to fix the
P1 full-discovery issue) bypassed normal discovery's bundled-load-path
alias guard. If a user had a bundled plugin directory in their
plugins.load.paths, the installed-index fallback would treat it as a
valid config-origin candidate and potentially override/duplicate bundled
plugins.
Add resolvePackagedBundledLoadPathAlias check in discoverFromConfigPaths
before calling discoverFromPath, so bundled paths are skipped with a
warning diagnostic matching normal discovery behavior.
Add P2 regression test verifying bundled plugin load paths are ignored
on the installed-index path while real workspace load paths still work.
Ref. https://github.com/openclaw/openclaw/pull/99196
* fix(plugins): forward load-path diagnostics unconditionally in installed-index path
Previously, diagnostics from discoverFromConfigPaths were only forwarded
when at least one extra candidate survived filtering. Configs whose
plugins.load.paths contained only bundled aliases, missing paths, duplicates
already in the index, or scoped-out entries silently lost the normal
discovery warning or doctor hint.
Now extraDiagnostics is assigned outside the extraCandidates.length > 0
guard, so every config load-path diagnostic reaches the caller regardless
of whether a new candidate is merged.
Adds a focused regression test verifying that a bundled-only load path
still surfaces the expected alias-guard warning diagnostic.
🦞 diamond lobster: P2 fix, no new L2 evidence needed (regression test
covers the diagnostic-forwarding contract directly)
Ref. https://github.com/openclaw/openclaw/pull/99196
* fix(plugins): preserve requiresPlugins diagnostics for load paths in installed-index path
- [P2] Export addMissingRequiredPluginDiagnostics from discovery.ts for reuse
- [P2] Call addMissingRequiredPluginDiagnostics on combined index + load-path candidates before passing to loadPluginManifestRegistry
- [P2] Add regression tests: warns when load-path plugin requires missing plugin, does not false-warn when required plugin is already in index
🦞 diamond lobster: L2 + test coverage
Ref. https://github.com/openclaw/openclaw/pull/99196
* fix(plugins): add missing discovery.js mock exports for addMissingRequiredPluginDiagnostics
plugin-install.test.ts mocks discovery.js but the mock didn't include the
newly exported addMissingRequiredPluginDiagnostics, causing CI failures in
tests that exercise loadPluginManifestRegistryForInstalledIndex.
Also add discoverFromConfigPaths to the mock (already imported but was
only latent because the mock's code path wasn't triggered with load paths).
Ref. https://github.com/openclaw/openclaw/pull/99196
* fix(plugins): rebuild stale configured plugin indexes
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
* perf(plugins): cache existence probes within bundle manifest scan
Bundle plugin discovery re-probes the same marker paths (skills/, commands/,
agents/, .mcp.json, .lsp.json, settings.json, hooks/hooks.json) once in
detectBundleManifestFormat and again in loadBundleManifest's capability
builders. Across the bundled plugin tree this is thousands of redundant
synchronous fs.existsSync calls; #76209 reports 25.4s of self-time on a
Windows cold start.
Add a scan-scoped existence cache (plugin-scan-existence-cache.ts) entered
only around discoverBundleInRoot. pluginScanExistsSync memoizes inside the
active scan and falls back to plain fs.existsSync outside it, so install,
hooks, and doctor flows stay uncached. The cache is push/pop per
discoverBundleInRoot call (try/finally), so a later install/repair pass
re-reads the filesystem — no process-global staleness.
Measured on Windows over a 25-plugin fixture: 550 -> 325 fs.existsSync
calls (41% fewer), 294.75ms -> 208.49ms. Discovery results unchanged.
Closes#76209
* fix(plugins): drop unused test reset helper and satisfy oxlint
Remove __resetPluginScanExistenceCacheForTest: the scan cache is push/pop
balanced by try/finally in withPluginScanExistenceCache, so the stack never
leaks between tests and the helper was dead code. It also tripped oxlint
no-underscore-dangle. Refactor the integration test to count existsSync calls
via a const-returning helper so there is no useless assignment.
Extract shared normalization/coercion helpers into private @openclaw/normalization-core workspace package while preserving existing plugin SDK helper subpaths.\n\nAlso keeps direct normalization-core imports internal, wires UI/build/loader resolution, and replaces the slow PR network CodeQL lane with a fast added-line boundary scan while retaining full CodeQL for scheduled/manual runs.\n\nVerification: local moved tests, plugin SDK boundary tests, extension loader tests, agents-support shard, UI build/test, build artifacts, lint, workflow guards, autoreview, and GitHub CI passed on PR head 963d893715.
Fixes#88198.
Ignore top-level helper scripts in auto-discovered global/workspace extension roots so they do not become manifestless plugin candidates during config validation. Standalone plugin files remain supported when explicitly configured through `plugins.load.paths`, and docs now call out the supported path.
Verification:
- `node scripts/run-vitest.mjs src/plugins/discovery.test.ts src/config/config.plugin-validation.test.ts`
- `node scripts/run-oxlint.mjs src/plugins/discovery.ts src/plugins/discovery.test.ts src/config/config.plugin-validation.test.ts`
- `git diff --check`
- GitHub CI green at `93073bfa85ee294e644c623881ba59ba71d90975`
- `.agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main`
Thanks @mushuiyu886 for the fix and @mmhzlrj for the report.
Split the diffs viewer Shiki language pack into an external publishable plugin.
The diffs plugin keeps the default curated syntax set, while the new @openclaw/diffs-language-pack package carries the extended Shiki languages for npm and ClawHub distribution. The install metadata includes the external ClawHub spec, and the curated C# alias set keeps both c# and cs supported without the language pack.
Co-authored-by: Dallin Romney <dallinromney@gmail.com>
The deriveIdHint function already strips -provider from unscoped
package names (@openclaw/anthropic-provider -> anthropic) but does
not strip -plugin (@openclaw/xai-plugin -> xai-plugin instead of
xai). This causes ~30 spurious 'plugin id mismatch' warnings on
gateway startup for built-in plugins whose package names end in
-plugin.
Closes#85048
* perf(plugins): extend discovery threading to loader, manifest registry, installed-index, and config contracts
Follow-up to #75451. Threads optional discovery?: PluginDiscoveryResult
through the remaining helpers that still call discoverOpenClawPlugins
internally during startup:
- loadOpenClawPlugins / loadOpenClawPluginCliRegistry (src/plugins/loader.ts):
add discovery? to PluginLoadOptions and consult it before falling back to
an internal scan at both call sites.
- loadPluginManifestRegistry (src/plugins/manifest-registry.ts): accept
discovery? as a more ergonomic alternative to the existing candidates? /
diagnostics? pair; candidates? still wins when both are supplied.
- resolveInstalledPluginIndexRegistry (src/plugins/installed-plugin-index-registry.ts):
add discovery? to LoadInstalledPluginIndexParams and use it when
candidates aren't supplied.
- resolvePluginConfigContractsById (src/plugins/config-contracts.ts): add
discovery? and thread it into the bundled-fallback discovery call.
Add discovery-threading.test.ts asserting each entry point skips its
internal discoverOpenClawPlugins call when discovery is supplied, calls it
when nothing is supplied, and prefers explicit candidates over discovery
when both are present (6 tests, all pass).
discoverOpenClawPlugins remains stateless; sharing is function-scoped per
src/plugins/CLAUDE.md guidance. Backward compatible: every change is
additive (new optional param).
* perf(plugins): drop verbose JSDoc from discovery? params
* perf(plugins): scan-scoped package.json cache in discovery
Adds a per-scan Map<string, PackageManifest | null> threaded through
discoverFromPath/discoverInDirectory/readCandidatePackageManifest, keyed
by the directory's resolved real path. Within one discovery scan, a
plugin's package.json is now read from disk once and reused across the
overlapping discovery code paths (bundled overlay scan, stock-root scan,
source-checkout extensions scan, installed-path scan, global-root scan)
that previously each fired their own read.
The cache lifetime is one scan (created in runPluginDiscovery alongside
the existing realpathCache and seen Set, dies when the scan returns).
discoverOpenClawPlugins remains stateless externally; no persistent
metadata cache.
* perf(plugins): expose raw parsed package.json on PluginCandidate
Discovery already reads each plugin's package.json once and produces a
parsed PackageManifest object before distilling it into metadata via
getPackageManifestMetadata. Currently only the distilled metadata is
kept on the candidate; the full parsed manifest is discarded.
Store the full parsed manifest on rawPackageManifest so downstream
consumers iterating candidates can use it instead of re-reading from
disk. This is the candidate-side groundwork for the scenario-C followup
that routes consumers (bundled-plugin-metadata, bundle-* helpers, etc.)
through the cached field; those consumers currently do their own
directory scans and would need to be refactored to iterate
PluginCandidate arrays before they can benefit.
The field is a frozen-at-discovery-time snapshot, same lifetime semantics
as the existing packageManifest / packageName / packageVersion fields on
PluginCandidate. No new staleness window introduced.
* perf(plugins): make package-manifest cache key trust-aware
Simplify plugin installation and runtime loading around package-manager-owned dependencies, with Jiti reserved for local/TS fallback paths.
Also scans npm plugin install roots so hoisted transitive dependencies are covered by dependency denylist and node_modules symlink checks.
ljy-1351