OpenClaw merged a plugin lifecycle fix for multi-entry packed plugin packages. PR #121174, titled "fix(plugins): keep packed entries consistent through package lifecycle," addresses a subtle but important ownership problem around plugin reloads, updates, trust state, rollback, and uninstall.
The short version: one package can contain multiple runtime plugin entries, but the package itself must remain the install owner. Before this fix, entries from an installed multi-entry package could collapse back to the package ID after a cold reload. From there, OpenClaw could treat each child as if it owned separate package bytes during update, trust, removability, or uninstall flows.
Package Owner, Runtime Children
The new model draws a firmer line between package ownership and runtime addressability. The package owns install lifecycle concerns: trust, precedence, update, removability, directory cleanup, rollback generations, and uninstall. Runtime children remain independently addressable for enablement, routing, capabilities, diagnostics, and slots.
That distinction matters because a packed plugin package is both one artifact and multiple runtime surfaces. Users may enable or route a specific child, but updating the package should update the shared package exactly once. Uninstalling through any child should remove the remaining siblings and shared install record exactly once.
What Changed
The installed index now persists each child's package owner as additive metadata inside the existing JSON payload. Older readers tolerate the new field, and the PR does not add a SQLite schema migration.
OpenClaw also routes lifecycle actions through a shared closed resolver used by CLI and management paths. During an update, the system snapshots the old child set, installs and discovers the replacement, reconciles retired child policy, validates ownership, commits durable config and index state, then releases rollback generations.
The fail-closed behavior is notable. Missing or ambiguous owner metadata does not get guessed. Instead, OpenClaw refuses the lifecycle mutation and points toward refresh, reinstall, or doctor-style recovery guidance.
User Impact
For users, the fix should make packed plugin packages feel more predictable after restarts and updates. Each packed entry keeps its exact ID and enablement after a cold reload. Updating through either the package owner or one child updates the shared package while preserving unrelated plugins. Removed or renamed children have their stale policy cleaned up.
That is especially important as ClawHub and package-based plugin distribution grow. Multi-entry packages are a natural way to ship a bundle of related tools, channel adapters, or runtime capabilities. The lifecycle rules need to be boring and durable, because plugin identity is also tied to trust and policy.
Verification
The PR includes a pre-fix reproduction where cold reconstruction expected two child entries but produced the package ID instead. The final evidence covers CLI, discovery, registry, persistence, update, uninstall, management, rollback, and Control UI tests, plus a packaged Docker lifecycle run that exercised child-addressed update and uninstall behavior.
The Bottom Line
PR #121174 is not a cosmetic plugin fix. It makes OpenClaw's package lifecycle model match the way packed plugins are actually distributed: one install owner, multiple runtime children, and no guessing when ownership evidence is missing.
That is the kind of infrastructure work that keeps plugin ecosystems from becoming fragile as they scale.