Independent OpenClaw reporting, releases, guides, and community coverage
OpenClaw News

OpenClaw Reuses Plugin Reload Registries

OpenClaw PR #149648 reuses the published inbound registry during plugin reloads to avoid redundant registrations.

Filed under Posts 2 min read Updated Sep 16, 2026
OpenClaw Reuses Plugin Reload Registries

OpenClaw merged PR #149648, a P2 plugin reload repair that reuses the published inbound registry during reload preparation.

This is the top layer of a five-PR partial memory repair stack. The PR says all five layers landed on September 16, with final receipts and before/after proof attached to the source discussion.

What Changed

The reload operation cache could hide newly published metadata from inbound preparation. That could cause OpenClaw to perform a redundant third registration instead of reusing the Gateway registry for the exact metadata generation and unchanged activation inputs.

The fix routes reuse through the existing registry-owned activation validator. Reuse now requires the same generation plus matching configuration, environment, workspace, and activation inputs. Model-selected discovery remains separate.

In practical terms, reloads can reuse what is already valid without collapsing distinct discovery paths into one bucket.

Why It Matters

Plugin reloads are one of the pressure points in a long-running agent runtime. If reloads keep recapturing or re-registering unchanged work, memory and lifecycle accounting become harder to reason about.

PR #149648 does not claim the entire memory campaign is finished. In fact, the PR is careful about its limit: the combined ESM forced-GC endurance result remains 36.65 MiB against a 32 MiB limit, and that partial repair boundary is explicitly accepted. That kind of caveat is useful because it keeps the story grounded.

What this layer does provide is a cleaner reload path for inbound preparation. It avoids redundant registration when the published registry is still the right owner, while leaving model-selected discovery to keep its separate registration.

The Proof

The PR reports that the real operation-cache regression fails against the prior owner and passes with the repair. It also cites 90 owner and sibling cases, CJS and ESM diagnostics that reduce registrations per replacement from three to two, and a 120-update ESM diagnostic covering RPC, tool, and HTTP tuples plus candidate disposal.

The combined tree for the stack is reported as passing 356 tests across 18 files. The final original eight-file group later passed 365 cases after a Telegram fixture teardown race was corrected.

What To Watch

This is not a public API change, schema migration, or configuration update. It is runtime hygiene: fewer duplicate registrations, clearer activation validation, and tighter ownership around reload preparation.

For teams running plugin-heavy OpenClaw environments, that kind of work pays off over time. Reloads become more predictable, and future memory repairs have a cleaner base to build on.

Daily Briefing

Get the Open-Source Briefing

The stories that matter, delivered to your inbox every morning. Free, no spam, unsubscribe anytime.

Join 45,000+ developers. No spam. Unsubscribe anytime.