OpenClaw Stops skills update From Destroying Local Skill Changes

An update command that destroys local work is worse than no update command, because it does its damage while appearing to perform routine maintenance. PR #118190 fixes exactly that shape in openclaw skills update: the command always passed force: true to the ClawHub installer, and the shared package sink then replaced the tracked skill directory and deleted its backup even when the installed tree no longer matched the recorded skillFile and fileTreeSha256 digests. Local edits were silently discarded by the very tooling that knew they existed.

The failure, precisely

Skills carry integrity metadata — per-file hashes and a tree digest — recorded at install time. That metadata exists precisely so an updater can tell “pristine install, safe to replace” apart from “operator modified this.” The bug bypassed that judgment entirely: every update behaved as force-overwrite. The sink replaced the directory and removed its backup in the same operation, so there was no recovery artifact left behind.

Concretely: an operator who tuned a skill’s prompts, fixed a broken pattern, or adapted templates to their workflow lost those changes on the next routine skills update — with output that looked like a successful update.

The fix

The merged change stops the unconditional force. The updater now consults the digests before touching anything: pristine trees update normally, and trees that diverge from their recorded state are preserved rather than clobbered, keeping the operator’s local changes intact. Upstream carried the change with its highest review-tier rating and a P1 priority label, reflecting that silent destruction of user work sits at the top of the severity ladder even when no security boundary is crossed.

Interpretation: the pre-fix behavior inverted the safe default. Version-control hygiene normally treats local modifications as something an update must surface, not erase. Post-fix, skills update finally respects the contract its own metadata was designed for.

Operator actions

1. Inventory locally customized skills on affected builds now, before the next update. Compare each skill directory against a fresh install or the ClawHub source; anything that differs is work the old updater would have destroyed.
2. Move durable customizations under version control. Whether that is a dotfiles repo, a fork of the skill package, or OpenClaw’s own workspace conventions, the fix protects divergence going forward but cannot restore what earlier updates already erased.
3. After upgrading, rehearse on a disposable profile: modify a scratch skill, run skills update, confirm the modification survives and the update completes without forcing.
4. Re-check any skill that recently “lost” behavior. If a skill mysteriously reverted to stock behavior in recent weeks on an affected build, treat the upstream package version — not your team — as the likely explanation.

Scope and limits

This fix covers openclaw skills update and the shared installer sink it drives. Hand-installed skills outside the tracked layout, and unrelated openclaw update flows, behave as before. The repair prevents future loss; reconstruction of previously destroyed local edits is out of reach unless you hold copies elsewhere.

Bottom line

If anyone on your team has ever edited a skill in place, upgrade to a containing build before running another skills update, salvage any customization still present, and put it somewhere an updater respects. The tool now keeps its hands off local work — but only builds with this fix do.