Summary

• Problem: plugin update failures with disableOnFailure only disabled plugins.entries.<id> and could leave stale plugins.allow, plugins.deny, and selected plugin slots pointing at the disabled plugin.
• Why it matters: after a failed external plugin update, operators could see a half-disabled config where the context-engine slot still referenced a plugin that OpenClaw had just disabled.
• What changed: failed-update disable now also removes the disabled plugin from allow/deny lists and resets selected memory / contextEngine slots to their defaults while preserving the install record for later repair.
• What did NOT change: no plugin install, package scanning, fallback-channel selection, or uninstall behavior changed.

Change Type

• Bug fix

Scope

• API / contracts
• UI / DX

Linked Issue/PR

• Closes: N/A
• Related: v2026.5.12-beta.5 plugin update disables lossless-claw after @beta fallback and leaves stale contextEngine config #81499
• Fixes bug/regression: Yes

Real behavior proof

• Behavior or issue addressed: failed plugin updates that disable a plugin now leave config policy and selected slots consistent with the disabled entry.
• Real environment tested: local OpenClaw repo checkout on Windows, Node 24.14, using the real updateNpmInstalledPlugins production helper with a synthetic local config and no external credentials.
• Exact steps or command run after this patch:

node_modules\.bin\tsx.cmd -e "import { updateNpmInstalledPlugins } from './src/plugins/update.ts'; void (async () => { const result = await updateNpmInstalledPlugins({ config: { plugins: { allow: ['demo', 'keep'], deny: ['demo', 'blocked'], slots: { memory: 'demo', contextEngine: 'demo' }, entries: { demo: { enabled: true } }, installs: { demo: { source: 'npm', spec: 'not a valid spec?', installPath: '/tmp/demo' } } } }, pluginIds: ['demo'], disableOnFailure: true, logger: { warn: () => undefined } }); console.log(JSON.stringify({ changed: result.changed, entry: result.config.plugins?.entries?.demo, allow: result.config.plugins?.allow, deny: result.config.plugins?.deny, slots: result.config.plugins?.slots, installPreserved: Boolean(result.config.plugins?.installs?.demo), outcome: result.outcomes[0]?.status }, null, 2)); })();"

• Evidence after fix:

{
  "changed": true,
  "entry": {
    "enabled": false
  },
  "allow": [
    "keep"
  ],
  "deny": [
    "blocked"
  ],
  "slots": {
    "memory": "memory-core",
    "contextEngine": "legacy"
  },
  "installPreserved": true,
  "outcome": "skipped"
}

• Observed result after fix: the failed-update disable path disables the plugin entry, removes stale allow/deny references, resets both selected slots to defaults, preserves the install record, and records the update as skipped.
• What was not tested: a live beta update against the public npm registry and the specific third-party lossless-claw package from v2026.5.12-beta.5 plugin update disables lossless-claw after @beta fallback and leaves stale contextEngine config #81499.
• Before evidence: source inspection on current main showed disablePluginConfigEntry() only set entries.<id>.enabled = false and did not touch allow/deny or slots.

Root Cause

• Root cause: the failed-update disable helper only updated the plugin entry, unlike explicit uninstall config cleanup which already removes policy references and resets selected slots.
• Missing detection / guardrail: no regression test covered disableOnFailure with a plugin selected in policy lists and plugin slots.
• Contributing context: plugin update failure handling preserves install records so repair/reinstall remains possible, but dependent runtime config still needs to stop selecting the disabled plugin.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/plugins/update.test.ts
• Scenario the test should lock in: an npm plugin update failure with disableOnFailure clears stale allow/deny references and resets selected memory/context-engine slots while preserving the install record.
• Why this is the smallest reliable guardrail: the bug is pure config mutation in the update failure path, so a focused plugin update test covers the contract without registry access.
• Existing related coverage: existing disable coverage checked the entry and install record only, not policy lists or slots.

User-visible / Behavior Changes

After an external plugin update failure disables a plugin, plugin policy and selected plugin slots are kept consistent with that disabled state. A context-engine plugin disabled during update now leaves the slot reset to legacy instead of continuing to point at the disabled plugin.

Diagram

Before:
plugin update failure -> entries.demo.enabled=false -> allow/deny/slots may still point at demo

After:
plugin update failure -> entries.demo.enabled=false -> allow/deny remove demo -> slots reset to defaults

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• Risk + mitigation: N/A

Repro + Verification

Environment

• OS: Windows
• Runtime/container: local OpenClaw checkout, Node 24.14
• Model/provider: N/A
• Integration/channel: plugin update config path
• Relevant config: synthetic plugin config with demo selected in allow, deny, slots.memory, and slots.contextEngine

Steps

1. Run the local after-fix tsx proof above.
2. Run the focused regression test for stale policy/slot cleanup.
3. Run the adjacent existing disable regression test.
4. Run formatting and diff checks.

Expected

• Failed-update disable marks the plugin entry disabled.
• Stale allow/deny references are removed.
• Selected memory/context-engine slots reset to defaults.
• The install record remains available for later repair.

Actual

• Local proof produced entry.enabled=false, allow=["keep"], deny=["blocked"], slots.memory="memory-core", slots.contextEngine="legacy", installPreserved=true, and outcome="skipped".
• Focused stale policy/slot regression test passed.
• Existing disable regression test passed.
• git diff --check and oxfmt passed.

Evidence

• Trace/log snippets

Human Verification

• Verified scenarios: failed-update disable cleans policy lists and resets memory / contextEngine slots while preserving the install record.
• Edge cases checked: existing entry config is still preserved by the adjacent disable test.
• What you did not verify: live third-party package update or public npm registry fallback behavior.

Review Conversations

• Addressed bot review conversations: N/A
• Unresolved conversations needing reviewer or maintainer judgment: N/A

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• Exact upgrade steps: N/A

Risks and Mitigations

• Risk: resetting a selected slot during failed-update disable changes the active fallback sooner than before.
  • Mitigation: this only happens after OpenClaw has already disabled the plugin due to an update failure; resetting to the existing default prevents a stale selection from pointing at the disabled plugin.