openclaw - 💡(How to fix) Fix openclaw update silently downgrades and rewrites pinned direct-dependency versions

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

  1. openclaw update should 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.

Fix Action

Fix / Workaround

When the bundled version is older than what the user had pinned, this is a silent downgrade — installed packages move backward across an openclaw update run, including past hotfix releases that were applied deliberately.

  • LCM 0.11.2 contains hotfixes (#712, #714, #717) that were applied deliberately. An openclaw update to 2026.5.20 silently reverts to 0.10.0 and reintroduces the bugs those hotfixes addressed, with no message that a downgrade occurred.
  • The same pattern would affect any other bundled-plugin dependency whose user-pinned version is newer than what the target Openclaw release considers bundled. LCM is the visible case today; the mechanism is general.
  • After the update, package.json and pnpm-lock.yaml disagree about the resolved version, leaving the install in a state where a pnpm install --frozen-lockfile and a fresh pnpm install would produce different trees.

Code Example

openclaw update --tag 2026.5.20 --no-restart --yes

---

Installing @martian-engineering/lossless-claw@0.10.0 into /home/captain/.openclaw/npm…
RAW_BUFFERClick to expand / collapse

Problem

openclaw update --tag <version> overwrites a user-pinned version of @martian-engineering/lossless-claw in ~/.openclaw/npm/package.json and reinstalls the version Openclaw considers bundled with the target release. There is no warning, no --allow-downgrade style gate, and no way to opt out short of editing package.json again 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 update run, including past hotfix releases that were applied deliberately.

Reproduction

Starting state (verified):

  • Openclaw 2026.5.19 installed
  • ~/.openclaw/npm/package.json dependencies contains "@martian-engineering/lossless-claw": "0.11.2" (the current npm dist-tag latest, published 2026-05-20)
  • node_modules/@martian-engineering/lossless-claw/package.json reports "version": "0.11.2"

Action:

openclaw update --tag 2026.5.20 --no-restart --yes

Observed (from update's own stdout):

Installing @martian-engineering/[email protected] into /home/captain/.openclaw/npm…

Post-update state:

  • ~/.openclaw/npm/package.json dependencies now contains "@martian-engineering/lossless-claw": "0.10.0" (rewritten by openclaw update)
  • node_modules/@martian-engineering/lossless-claw/package.json reports "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.yaml still carries the 0.11.2 resolution entry, so the lockfile and package.json are 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:

  1. openclaw update should 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.

  2. If a user has explicitly pinned a dependency in package.json, openclaw update should 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

  • LCM 0.11.2 contains hotfixes (#712, #714, #717) that were applied deliberately. An openclaw update to 2026.5.20 silently reverts to 0.10.0 and reintroduces the bugs those hotfixes addressed, with no message that a downgrade occurred.
  • The same pattern would affect any other bundled-plugin dependency whose user-pinned version is newer than what the target Openclaw release considers bundled. LCM is the visible case today; the mechanism is general.
  • After the update, package.json and pnpm-lock.yaml disagree about the resolved version, leaving the install in a state where a pnpm install --frozen-lockfile and a fresh pnpm install would produce different trees.

Notes

  • PR #81435 ("preserve managed plugin peer dependencies") and PR #81450 ("plan managed npm peer pins with npm") landed in the same area but target peer dependencies. @martian-engineering/lossless-claw appears as a direct entry in dependencies (not in managedPeerDependencies), so the recent fixes don't cover this path.
  • The Openclaw tarball for 2026.5.20 does not list @martian-engineering/lossless-claw in either dependencies or peerDependencies, so the 0.10.0 version is being supplied from a bundled-plugin manifest internal to openclaw 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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Two related expectations, the first stronger than the second:

  1. openclaw update should 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.

  2. If a user has explicitly pinned a dependency in package.json, openclaw update should 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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix openclaw update silently downgrades and rewrites pinned direct-dependency versions