* fix(plugins): align hook and tool registrations
Reuse gateway-owned plugin registrations for matching hooks and tools while loading only missing tool owners from narrower runtime scopes.\n\nCo-authored-by: w33d <w33d@steadholme.local>
* test(plugins): cover mixed registry tool owners
Verify gateway-pinned and compatible active registrations compose without another plugin load.
Co-authored-by: w33d <w33d@steadholme.local>
* refactor(plugins): keep pinned registry lookup internal
Reuse the existing runtime-state contract so hook and tool ownership does not expand the Plugin SDK surface or treat unpinned active registries as Gateway owners.
* test(plugins): complete hook context fixture
Supply the required tool name in the stateful hook ownership regression context.
* chore: leave contributor release note in PR
Normal contributor PRs do not modify the release-owned changelog; the PR body retains the release note and attribution.
* fix(plugins): align partial registry owners
* fix(plugins): preserve scoped tool diagnostics
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Co-authored-by: w33d <w33d@steadholme.local>
Adds client-capability-gated tool availability: gateway clients declare
capabilities at connect (new inline-widgets cap), chat.send stamps them into
the run context, and every tool assembly path (embedded runner, queued
followups, Codex app-server harness, plugin-only construction plans) drops
tools whose requiredClientCaps the originating client did not declare. The
Canvas plugin ships the first such tool, show_widget: agents pass SVG or an
HTML fragment plus a title; the plugin hosts it as a bounded, retention-scoped
Canvas document and returns the existing canvas preview handle, which web chat
renders as a sandboxed iframe fitted to the widget's reported content height.
Widget frames never get allow-same-origin (per-preview sandbox ceiling,
including the sidebar path) and the Canvas host serves widget documents with a
CSP sandbox header so direct navigation runs in an opaque origin. Verified
live end-to-end on a Testbox with gpt-5.5 (screenshots on the PR). CLI-backed
model backends do not carry client caps yet and stay fail-closed (#102577).
Closes#101790
Keep plugin tool discovery request-local, preserve active provider/channel registries, and carry the prepared registry through MCP and catalog resolution.
Co-authored-by: 郑苏波 (Super Zheng) <superzheng@tencent.com>
Recover assistant turns that complete tool work without producing a visible final answer, while preserving intentional silent replies.
Use concrete tool-instance replay safety across embedded, Codex, and Copilot runtimes so unknown, mutating, async-started, and durable recall operations fail closed. Preserve genuine empty Codex final items without promoting commentary or tool-progress echoes.
Supersedes #90872. Thanks @fuller-stack-dev.
Co-authored-by: fuller-stack-dev <263060202+fuller-stack-dev@users.noreply.github.com>
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.
Fix plugin tool discovery when a selected wildcard plugin set is resolved against a partial active registry.\n\nRequire scoped registries to cover every requested plugin owner, force cold-load incomplete tool discovery registries without replacing active plugin runtime state, and add regression coverage for the partial-registry path.\n\nFixes #76780.\nThanks @lilesjtu.
`resolvePluginTools` returned an empty tool list when no pre-warmed
channel/active registry was found after startup — the on-demand fallback
removed by PR #76004 was only added back for memory and capability-provider
surfaces, leaving path-based (origin "config") plugin tool factories silent.
Fix: when `resolvePluginToolRegistry` returns null, trigger a standalone
registry load via `ensureStandaloneRuntimePluginRegistryLoaded`, then retry.
Adds regression test asserting tools are resolved without pre-warming.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary:
- The PR makes `tools.profile: "full"` resolve to a wildcard allowlist, teaches plugin optional-tool allowlist checks to honor `*`, and updates regression tests, docs, and the changelog for browser tool availability.
- Reproducibility: yes. source-level reproduction is high confidence: current main makes `full` resolve to no ... plugin allowlist helpers do not accept `*`. I did not run a live browser session in this read-only review.
Automerge notes:
- PR branch already contained follow-up commit before automerge: docs: update full profile description and add changelog for #76507
Validation:
- ClawSweeper review passed for head b5329de33c.
- Required merge gates passed before the squash merge.
Prepared head SHA: b5329de33c
Review: https://github.com/openclaw/openclaw/pull/76557#issuecomment-4365736091
Co-authored-by: Alex Knight <aknight@atlassian.com>
Reuse the startup runtime plugin registry across provider/tool helper paths while preserving standalone CLI/MCP fallback loading.
Includes follow-up fixes for migration/provider/tool registry bootstrap and regression coverage for compatible registry reuse.
Co-authored-by: DmitryPogodaev <pogodaev.dm@gmail.com>
Peter Steinberger