[Bug]: openclaw plugins update never upgrades ClawHub-sourced plugins — spec field always pins resolved version

[kangsen1234]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw plugins update never upgrades ClawHub-sourced plugins to a newer version because the install flow always writes the resolved version into the spec field (e.g. clawhub:@pkg@0.0.2), causing update to re-resolve the same pinned version instead of fetching the latest from ClawHub.

Steps to reproduce

1. Publish 0.0.2 versions of a plugin to ClawHub
2. Install the older version:
   openclaw plugins install plugin
3. Confirm spec is pinned in ~/.openclaw/openclaw.json:
   "spec": "plugin@0.0.2"
   3.1. Publish 0.0.3 versions of a plugin to ClawHub
4. Run: openclaw plugins update plugin
5. Observe it resolves to 0.0.2 and reports "already at 0.0.2".

Expected behavior

When no version is specified during install, the spec should be saved without a version , consistent with how npm installs work . This way, plugins update can resolve to the latest ClawHub version. The official docs state: "previously stored dist-tags such as @beta and exact pinned versions continue to be used" — implying that unpinned installs should resolve to latest on update.

Actual behavior

The clawhub install handler always writes the resolved version into the spec field, regardless of whether the user specified a version. As a result, plugins update always re-resolves the same pinned version and never upgrades.

OpenClaw version

2026.3.31

Operating system

macOS 15.1.1

Install method

npm global

Model

N/A — this is a CLI plugin management bug, not model-related.

Provider / routing chain

N/A

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

[steipete]

Codex maintainer review on current main: confirmed still real.

Evidence from source:

• plugins install clawhub:demo persists the resolved ClawHub version into the durable install record spec: src/cli/plugins-install-command.ts:515 writes source: "clawhub", and src/cli/plugins-install-command.ts:517 formats the saved spec with result.clawhub.version.
• The bare-spec ClawHub-preferred path does the same at src/cli/plugins-install-command.ts:548 / :550.
• plugins update then treats non-npm records as record.spec and passes that exact value back to ClawHub (src/plugins/update.ts:487, src/plugins/update.ts:688). If install saved clawhub:demo@1.2.3, update re-resolves 1.2.3 instead of latest.
• There is a useful updater test for an unpinned ClawHub record (src/plugins/update.test.ts:718 expects spec: "clawhub:demo"), but the current install path does not create that unpinned record for normal unpinned installs.

So the issue is not just historical config drift. Best fix looks like: preserve the user-requested selector in the install record (clawhub:name for unpinned installs, clawhub:name@tag-or-version when explicitly requested), while continuing to store the resolved version, integrity, and resolvedAt metadata separately. Please include a regression that exercises install -> update, not only the updater with a hand-built unpinned record.

[steipete]

Fixed on main in 3af34316f2.

Root fix: CLI ClawHub installs now preserve the requested selector in the install record instead of rewriting unpinned installs to the initially resolved version. That keeps openclaw plugins update able to follow newer ClawHub releases while explicit selectors such as clawhub:pkg@1.2.3 and pkg@beta stay pinned.

Validation on Blacksmith Testbox tbx_01kq72yf88x8sbgjzj2tfr0n2q:

• pnpm test src/cli/plugins-cli.install.test.ts src/plugins/update.test.ts
• pnpm check:changed