Summary

Describe the problem and fix in 2–5 bullets:

• Problem: openclaw plugins doctor could load a plugin that calls deprecated api.runtime.config.loadConfig() / writeConfigFile(...), print an anonymous runtime-config-load-write warning, then still report no plugin issues.
• Why it matters: operators could not tell which plugin or path triggered the warning, so the output was noisy instead of actionable.
• What changed: deprecated runtime config warnings now run inside the owning plugin scope and include the plugin id plus source path; warning dedupe is per plugin/API so multiple offending plugins can be identified.
• What did NOT change (scope boundary): no plugin migration, no plugin update fallback-summary work, no restart-health/update-message work, and no change to the deprecated compatibility helpers themselves.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes v2026.5.12-beta.4 npm update succeeds but restart phase reports stale CLI/config-version mismatch #81394
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

External contributors must show after-fix evidence from a real OpenClaw setup. Unit tests, mocks, lint, typechecks, snapshots, and CI are supplemental only. Screenshots are encouraged even for CLI, console, text, or log changes; terminal screenshots and copied live output count. Be mindful of private information like IP addresses, API keys, phone numbers, non-public endpoints, or other private details when providing evidence.

• Behavior or issue addressed: anonymous runtime config deprecation warnings are now attributed to the plugin id/source that triggered them.
• Real environment tested: local OpenClaw worktree in the maintainer Docker dev container on macOS.
• Exact steps or command run after this patch:
  1. git diff --check
  2. pnpm test src/plugins/runtime/runtime-config.test.ts src/plugins/registry.runtime-config.test.ts
  3. pnpm test src/cli/plugins-cli.list.test.ts
  4. pnpm tsgo
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): targeted tests passed locally, including attribution assertions for plugin "legacy-plugin" runtime config.loadConfig() and plugin "legacy-plugin" runtime config.writeConfigFile() plus registry-scope assertions.
• Observed result after fix: runtime config deprecation warnings emitted from plugin-scoped runtime helpers include the plugin id and source path.
• What was not tested: a live third-party plugin installed into a real user config and run through openclaw plugins doctor end-to-end.
• Before evidence (optional but encouraged): issue v2026.5.12-beta.4 npm update succeeds but restart phase reports stale CLI/config-version mismatch #81394 reports the previous output as plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current(). followed by No plugin issues detected.

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause: the deprecated runtime config helpers logged through shared runtime code without reading the plugin identity already available in the per-plugin runtime proxy.
• Missing detection / guardrail: tests covered the compatibility warning text, but not plugin-scoped attribution for operator-facing diagnostics.
• Contributing context (if known): the warning cache deduped only by helper name, so even after attribution only the first offending plugin would have been visible without per-plugin dedupe.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

• 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/runtime/runtime-config.test.ts, src/plugins/registry.runtime-config.test.ts, src/cli/plugins-cli.list.test.ts
• Scenario the test should lock in: deprecated loadConfig and writeConfigFile warnings include plugin id/source when called under plugin scope, and per-plugin runtime config helpers receive the owning plugin scope from the registry proxy.
• Why this is the smallest reliable guardrail: it exercises the runtime warning formatter and the registry seam that injects plugin-scoped runtime helpers without needing a full external plugin install fixture.
• Existing test that already covers this (if any): src/cli/plugins-cli.list.test.ts still covers the clean doctor success path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Deprecated plugin runtime config warnings now include plugin identity and source path when emitted from plugin-scoped runtime helpers.

Diagram (if applicable)

Before:
[plugin calls deprecated config helper] -> [shared warning without plugin id] -> [operator cannot identify source]

After:
[plugin calls deprecated config helper] -> [plugin-scoped runtime proxy] -> [warning includes plugin id/source]

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 host with OpenClaw Docker dev container
• Runtime/container: Node 24 dev container via openclaw-shell
• Model/provider: N/A
• Integration/channel (if any): plugins runtime / CLI doctor diagnostics
• Relevant config (redacted): N/A

Steps

1. Run the runtime config and registry attribution tests.
2. Run the plugins CLI doctor/list tests.
3. Run core tsgo.

Expected

• Deprecated runtime config warnings are attributed to plugin id/source under plugin scope.
• Existing plugins doctor clean-output tests continue to pass.
• Typecheck passes.

Actual

• pnpm test src/plugins/runtime/runtime-config.test.ts src/plugins/registry.runtime-config.test.ts: 2 files passed, 7 tests passed.
• pnpm test src/cli/plugins-cli.list.test.ts: 1 file passed, 9 tests passed.
• pnpm tsgo: passed.

Evidence

Attach at least one:

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

Regression tests now assert warning strings like:

plugin "legacy-plugin" runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current(). Source: /plugins/legacy-plugin/index.js
plugin "legacy-plugin" runtime config.writeConfigFile() is deprecated (runtime-config-load-write); use config.mutateConfigFile(...) or config.replaceConfigFile(...). Source: /plugins/legacy-plugin/index.js

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: attributed warning formatting, per-plugin warning dedupe, registry proxy scoping for deprecated config helpers, existing CLI doctor/list tests.
• Edge cases checked: duplicate calls from the same plugin warn once; calls from a second plugin warn separately; nested plugin scope does not retain stale pluginSource when only a new plugin id is supplied.
• What you did not verify: a live external plugin installed in a real operator config and run through full openclaw plugins doctor.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

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: additional warning lines if multiple plugins use the same deprecated helper.
  • Mitigation: warnings are still deduped per plugin/API, and the added lines are actionable instead of anonymous.
• Risk: plugin scoping accidentally drops request-scope fields.
  • Mitigation: withPluginRuntimePluginScope preserves the existing scope via object spread and only updates pluginId/pluginSource.