-
-
Notifications
You must be signed in to change notification settings - Fork 79.1k
openclaw update silently downgrades and rewrites pinned direct-dependency versions #85184
Copy link
Copy link
Open
Labels
P1High-priority user-facing bug, regression, or broken workflow.High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.ClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:data-lossCan lose, corrupt, or silently drop user/session/config data.Can lose, corrupt, or silently drop user/session/config data.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Metadata
Metadata
Assignees
Labels
P1High-priority user-facing bug, regression, or broken workflow.High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.ClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:data-lossCan lose, corrupt, or silently drop user/session/config data.Can lose, corrupt, or silently drop user/session/config data.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Problem
openclaw update --tag <version>overwrites a user-pinned version of@martian-engineering/lossless-clawin~/.openclaw/npm/package.jsonand reinstalls the version Openclaw considers bundled with the target release. There is no warning, no--allow-downgradestyle gate, and no way to opt out short of editingpackage.jsonagain post-install.When the bundled version is older than what the user had pinned, this is a silent downgrade — installed packages move backward across an
openclaw updaterun, including past hotfix releases that were applied deliberately.Reproduction
Starting state (verified):
~/.openclaw/npm/package.jsondependenciescontains"@martian-engineering/lossless-claw": "0.11.2"(the currentnpm dist-tag latest, published 2026-05-20)node_modules/@martian-engineering/lossless-claw/package.jsonreports"version": "0.11.2"Action:
Observed (from update's own stdout):
Post-update state:
~/.openclaw/npm/package.jsondependenciesnow contains"@martian-engineering/lossless-claw": "0.10.0"(rewritten byopenclaw update)node_modules/@martian-engineering/lossless-claw/package.jsonreports"version": "0.10.0"(downgraded from 0.11.2)Versions 0.11.0, 0.11.1, and 0.11.2 — all published before the update was run — were silently skipped, and the previously-installed 0.11.2 was replaced by 0.10.0.
pnpm-lock.yamlstill carries the 0.11.2 resolution entry, so the lockfile andpackage.jsonare inconsistent after the update.LCM 0.11.2's peerDependency declares
"openclaw": ">=2026.5.12", so the downgrade isn't required for 2026.5.20 compatibility — 0.11.2 is a valid choice.Expected behavior
Two related expectations, the first stronger than the second:
openclaw updateshould never silently downgrade an installed dependency. If the bundled version is older than what is installed, the update should at minimum warn loudly and require a flag to proceed. Today the only signal is one line of stdout among hundreds, and the user discovers the regression after the fact when missing fixes resurface.If a user has explicitly pinned a dependency in
package.json,openclaw updateshould probably respect the pin rather than rewriting it, even when the pin is higher than the bundled version. The pin is an expression of intent. If respecting the pin would violate a peerDependency constraint of the target Openclaw release, that's a separate conversation worth surfacing (warning, prompt, dedicated flag) rather than silently overriding.The downgrade-prevention case is the unambiguous half; the respect-the-pin case has more nuance and is open to design.
Impact
openclaw updateto 2026.5.20 silently reverts to 0.10.0 and reintroduces the bugs those hotfixes addressed, with no message that a downgrade occurred.package.jsonandpnpm-lock.yamldisagree about the resolved version, leaving the install in a state where apnpm install --frozen-lockfileand a freshpnpm installwould produce different trees.Notes
@martian-engineering/lossless-clawappears as a direct entry independencies(not inmanagedPeerDependencies), so the recent fixes don't cover this path.@martian-engineering/lossless-clawin eitherdependenciesorpeerDependencies, so the 0.10.0 version is being supplied from a bundled-plugin manifest internal toopenclaw update. I haven't traced the exact source path; happy to dig if it's useful.Environment: Linux 6.6.114.1-microsoft-standard-WSL2, Node v26.1.0, pnpm v10.33.4, openclaw 2026.5.20.