OpenClaw Removes 230 Expired Plugin Compatibility Surfaces on Main
A large SDK cleanup has landed on OpenClaw main. External plugin authors should audit legacy imports now, but packaged users should not mistake the merge for a released update.
OpenClaw has merged a large plugin-compatibility cleanup into its default branch. PR #111451 marks 230 dated compatibility records as removed, while leaving six date-eligible records pending because shipped public contracts still have known dependants.
This is a real compatibility event for external plugin authors, but it is not yet a packaged upgrade event. The change merged on 19 July at 18:04 UTC, after 2026.7.2-beta.3 was published. At verification time, npm still pointed latest to 2026.7.1-2 and beta to 2026.7.2-beta.3.
The decision
| Your situation | What to do |
|---|---|
| You maintain an external OpenClaw plugin | Audit imports and removed runtime hooks before testing the next package that includes this merge. |
| You use only bundled plugins on an npm release | Do not change production solely because this landed on main. Watch the next release notes. |
| You build OpenClaw from main | Treat this as a breaking plugin-contract boundary and test every installed third-party plugin before rollout. |
| You publish plugin tooling or templates | Stop teaching the removed root SDK and broad compatibility imports; point authors to documented focused subpaths. |
What was removed
The merge is much broader than deleting one alias. Its pull request reports 4,009 additions and 13,992 deletions across 526 files. The current migration guide says these prominent surfaces are now removed:
openclaw/plugin-sdkopenclaw/plugin-sdk/compatopenclaw/extension-apiapi.registerEmbeddedExtensionFactory(...)
The guide also says direct plugin runtime config helpers loadConfig and writeConfigFile have been removed. The broad infra-runtime and config-runtime barrels have separate later compatibility windows, but new plugin code is directed to focused SDK subpaths instead.
The practical failure mode is blunt: the official migration guide warns that plugins importing the removed root, compatibility or extension surfaces no longer load.
Why this deserves attention before the release
Waiting for a release to begin the audit compresses the migration into an upgrade window. External plugin authors can check their source now without installing unreleased OpenClaw.
Search the plugin’s imports and registrations for the named removed contracts. Then map each use to the canonical replacement in the merge-pinned SDK migration guide, rather than guessing from a similarly named internal module.
The most important documented migrations include:
- import focused
openclaw/plugin-sdk/<subpath>modules instead of either SDK root; - replace ambient config reads with configuration already passed into the call path,
api.runtime.config.current(), orctx.getRuntimeConfig()as appropriate; - route config writes through
mutateConfigFile(...)with an explicit after-write policy; - replace embedded tool-result extension handlers with
registerAgentToolResultMiddleware(...)and declare the targeted runtimes in the plugin manifest; and - move approval behavior from retired channel-plugin fields to the documented
approvalCapabilitycontract.
These are not mechanical search-and-replace operations in every plugin. Config freshness, restart policy, middleware runtime declarations and approval authorization are behavioural boundaries. Review and test them as such.
What remains compatible
The sweep did not delete every dated adapter. The pull request says six eligible records remain removal-pending because public contracts still have live dependants. The compatibility document also lists later August and September windows, including WhatsApp flat inbound callback aliases through 30 August 2026.
Doctor repair and migration compatibility is tracked separately from runtime compatibility. The official policy explicitly warns maintainers not to remove a doctor migration merely because the matching runtime adapter expired. That means an old configuration may still be repairable even when an old plugin import can no longer load.
Evidence and limits
The pull request reports a successful exact-head CI run, focused tests, package checks, and an upgrade test from published [email protected] to a packed candidate. The linked CI run completed successfully. Those are upstream project results, not an independent OpenClaw Academy reproduction.
We verified the merge status and timestamp through the GitHub API, inspected the migration and compatibility documents at merge commit c7e7ac2, and checked current GitHub release and npm distribution metadata. We did not build main, install the packed candidate, or run third-party plugins against it. Exact plugin breakage therefore remains untested source analysis until the relevant package ships and is independently exercised.
Bottom line
This is not a reason for ordinary npm users to upgrade today; there is no newer package to upgrade to. It is a reason for external plugin authors to audit today.
Remove dependence on the retired roots and hooks, use the merge-pinned migration map, and test against a disposable build before adopting whichever release first contains the sweep. The expensive option is discovering a dead plugin during the production upgrade.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF