vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-05-06 11:10:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

refactor(config): tighten plugin config guardrails

Browse Source
This commit is contained in:
Peter Steinberger
2026-04-27 13:46:23 +01:00
parent ef9d108436
commit 5dd1e264eb
16 changed files with 789 additions and 649 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/plugins/compatibility.md
View File

@@ -105,7 +105,8 @@ Current compatibility records include:
- legacy provider plugin hooks and type aliases while providers move to
explicit catalog, auth, thinking, replay, and transport hooks
- legacy runtime aliases such as `api.runtime.taskFlow`,
`api.runtime.subagent.getSession`, and `api.runtime.stt`
`api.runtime.subagent.getSession`, `api.runtime.stt`, and deprecated
`api.runtime.config.loadConfig()` / `api.runtime.config.writeConfigFile(...)`
- legacy memory-plugin split registration while memory plugins move to
`registerMemoryCapability`
- legacy channel SDK helpers for native message schemas, mention gating,

15
docs/plugins/sdk-migration.md
View File

@@ -119,12 +119,15 @@ releases.
Mutation results include a typed `followUp` summary for tests and logging;
the gateway remains responsible for applying or scheduling the restart.
`loadConfig` and `writeConfigFile` remain as deprecated compatibility
helpers for external plugins during the migration window and warn once when
called. Bundled plugins and repo runtime code are protected by scanner
guardrails in `pnpm check:deprecated-internal-config-api`: new production
plugin usage fails outright, direct config writes fail, gateway server
methods must use the request runtime snapshot, and long-lived runtime
modules have zero allowed ambient `loadConfig()` calls.
helpers for external plugins during the migration window and warn once with
the `runtime-config-load-write` compatibility code. Bundled plugins and repo
runtime code are protected by scanner guardrails in
`pnpm check:deprecated-internal-config-api` and
`pnpm check:no-runtime-action-load-config`: new production plugin usage
fails outright, direct config writes fail, gateway server methods must use
the request runtime snapshot, runtime channel send/action/client helpers
must receive config from their boundary, and long-lived runtime modules have
zero allowed ambient `loadConfig()` calls.
</Step>

2
docs/plugins/sdk-runtime.md
View File

@@ -41,7 +41,7 @@ Persist changes with `api.runtime.config.mutateConfigFile(...)` or `api.runtime.
The mutation helpers return `afterWrite` plus a typed `followUp` summary so callers can log or test whether they requested a restart. The gateway still owns when that restart actually happens.
`api.runtime.config.loadConfig()` and `api.runtime.config.writeConfigFile(...)` are deprecated compatibility helpers. They warn once at runtime, and bundled plugins must not use them; the architecture guard fails if production plugin code calls them or imports those helpers from plugin SDK subpaths.
`api.runtime.config.loadConfig()` and `api.runtime.config.writeConfigFile(...)` are deprecated compatibility helpers under `runtime-config-load-write`. They warn once at runtime, and bundled plugins must not use them; the config boundary guards fail if production plugin code calls them or imports those helpers from plugin SDK subpaths.
Internal OpenClaw runtime code has the same direction: load config once at the CLI, gateway, or process boundary, then pass that value through. Successful mutation writes refresh the process runtime snapshot and advance its internal revision; long-lived caches should key off the runtime-owned cache key instead of serializing config locally. Long-lived runtime modules have a zero-tolerance scanner for ambient `loadConfig()` calls; use a passed `cfg`, a request `context.getRuntimeConfig()`, or `getRuntimeConfig()` at an explicit process boundary.