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.
Update, 24 July: a later stress campaign found that the cleanup removed public exports still used by official Slack, Discord, Signal and Microsoft Teams packages published at
2026.7.1. PR #113101 restores those exact setup helpers and named schemas as deprecated compatibility adapters. It does not restore the broad SDK roots and hooks listed below for arbitrary external plugins. The same follow-up also fixes stale process-local install-record caches that could lose successful concurrent lifecycle mutations.
This was a real compatibility event for external plugin authors before it became a packaged upgrade question. The sweep merged on 19 July at 18:04 UTC, after 2026.7.2-beta.3 was published. Operators should now check the manifest of the exact later package they are considering for both PR #111451 and the corrective PR #113101 rather than inferring inclusion from a newer version number.
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 permanently delete every dated adapter. The original pull request left six eligible records removal-pending because public contracts still had live dependants, and PR #113101 subsequently restored the exact deprecated exports required by shipped official channel packages. The compatibility document also lists later August and September windows, including WhatsApp flat inbound callback aliases through 30 August 2026.
Plugin lifecycle reliability changed alongside the SDK correction. PR #112763 serializes complete lifecycle mutations through a shared cross-process lease and preserves setup-required installs as disabled, configurable and retryable instead of erasing ownership state. PR #113101 then invalidates each process’s cached install ledger after lease acquisition so a waiting process cannot overwrite newer records. Operators should still avoid overlapping plugin maintenance on an older build; a lock only helps once the containing fix is actually installed.
Hosted external-plugin feeds also gained a compatibility boundary in PR #110037. Live feeds must now use standard DSSE fields (payloadType, payload, and signatures[].keyid/sig); the pre-standard beta shape is accepted only while reading persisted snapshots. Mixed legacy and standard signatures remain rejected, and configured trust thresholds still require key IDs. Feed publishers should emit standard DSSE now. Operators carrying beta snapshots should let the bounded reader migrate them rather than rewriting signed bytes by hand.
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 openclaw@2026.4.23 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, by itself, a reason for ordinary npm users to upgrade. It remains a reason for external plugin authors to audit before adopting a package that contains the sweep.
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 and its shipped-package compatibility follow-up. Official 2026.7.1 channel packages have a targeted adapter path on current main; that is not a promise that arbitrary external imports from removed broad surfaces work again. 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.- 01Remove expired plugin compatibility surfaces — PR #111451↗
- 02Plugin SDK migration guide at the merge commit↗
- 03Plugin compatibility policy at the merge commit↗
- 04OpenClaw 2026.7.2-beta.3 release↗
- 05Official OpenClaw npm distribution tags↗
- 06Restore shipped Plugin SDK compatibility — PR #113101↗
- 07Serialize plugin lifecycle mutations — PR #112763↗
- 08Accept standard DSSE hosted-feed envelopes — PR #110037↗
THE OPERATOR BRIEF