From 59bd7e47e86b019c40b66be50b27e042a139aa12 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Tue, 28 Apr 2026 05:34:27 +0100 Subject: [PATCH] docs: avoid mdx lists inside callouts --- docs/plugins/architecture.md | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/docs/plugins/architecture.md b/docs/plugins/architecture.md index 9fba7fe34d9..2d8a4c683e3 100644 --- a/docs/plugins/architecture.md +++ b/docs/plugins/architecture.md @@ -440,12 +440,8 @@ When in doubt, raise the abstraction level: define the capability first, then le Native OpenClaw plugins run **in-process** with the Gateway. They are not sandboxed. A loaded native plugin has the same process-level trust boundary as core code. -Implications: - -- a native plugin can register tools, network handlers, hooks, and services -- a native plugin bug can crash or destabilize the gateway -- a malicious native plugin is equivalent to arbitrary code execution inside the OpenClaw process - +Native plugin implications: a plugin can register tools, network handlers, hooks, and services; a plugin bug can crash or destabilize the gateway; and a malicious native plugin is equivalent to arbitrary code execution inside the OpenClaw process. + Compatible bundles are safer by default because OpenClaw currently treats them as metadata/content packs. In current releases, that mostly means bundled skills. @@ -454,13 +450,8 @@ Use allowlists and explicit install/load paths for non-bundled plugins. Treat wo For bundled workspace package names, keep the plugin id anchored in the npm name: `@openclaw/` by default, or an approved typed suffix such as `-provider`, `-plugin`, `-speech`, `-sandbox`, or `-media-understanding` when the package intentionally exposes a narrower plugin role. -**Trust note:** - -- `plugins.allow` trusts **plugin ids**, not source provenance. -- A workspace plugin with the same id as a bundled plugin intentionally shadows the bundled copy when that workspace plugin is enabled/allowlisted. -- This is normal and useful for local development, patch testing, and hotfixes. -- Bundled-plugin trust is resolved from the source snapshot — the manifest and code on disk at load time — rather than from install metadata. A corrupted or substituted install record cannot silently widen a bundled plugin's trust surface beyond what the actual source claims. - +**Trust note:** `plugins.allow` trusts **plugin ids**, not source provenance. A workspace plugin with the same id as a bundled plugin intentionally shadows the bundled copy when that workspace plugin is enabled/allowlisted. This is normal and useful for local development, patch testing, and hotfixes. Bundled-plugin trust is resolved from the source snapshot — the manifest and code on disk at load time — rather than from install metadata. A corrupted or substituted install record cannot silently widen a bundled plugin's trust surface beyond what the actual source claims. + ## Export boundary