[BUG] M`/plugin marketplace update` + `/reload-plugins` does not pick up pushed plugin changes

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/69020
2. https://github.com/anthropics/claude-code/issues/60772
3. https://github.com/anthropics/claude-code/issues/71074

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Those look different to me. Maybe the difference is just surface level - apologies if so

Hi
Hitting the same core issue on a different surface — VS Code extension (Windows), git-backed marketplace (Azure DevOps, not GitHub, so it's provider-agnostic) — with one extra data point that narrows down where the break actually is.

Setup: plugin vendavo-vpp@vpp-marketplace, installed at 0.2.1. Pushed a commit to the marketplace's tracked branch that bumps the plugin's plugin.json version to 0.2.2 (so, unlike some other reports, the version string did change).

Repro (mirrors this issue, via the VS Code GUI instead of slash commands):

Manage Plugins → Marketplaces tab → click the refresh icon for the marketplace.
~/.claude/plugins/marketplaces/<marketplace>/ — git checkout is at the new commit. Marketplace-level refresh worked.
~/.claude/plugins/cache/<marketplace>/<plugin>/ — a new 0.2.2/ directory is freshly cached alongside the old 0.2.1/. The new version was fetched.
~/.claude/plugins/installed_plugins.json — still pinned to 0.2.1 / the old gitCommitSha, unchanged, even after a second marketplace refresh, a full "Developer: Reload Window," and updating the Claude Code CLI itself (2.0.58 → 2.1.212).
So exactly this issue's symptom: marketplace update "succeeds," but nothing re-points the installed plugin at the newer, already-cached version, and there's no UI signal that an update exists.

New data point: running the standalone command directly —

claude plugin update vendavo-vpp@vpp-marketplace
— worked correctly on the first try:

Checking for updates for plugin "vendavo-vpp@vpp-marketplace" at user scope…
✔ Plugin "vendavo-vpp" updated from 0.2.1 to 0.2.2 for scope user. Restart to apply changes.
installed_plugins.json immediately reflected version: "0.2.2", the new installPath, and the correct gitCommitSha.

So a full uninstall/reinstall cycle wasn't actually necessary on this end — claude plugin update <plugin>@<marketplace> alone did the correct version check and cache promotion, restart-to-apply included. That suggests the break is specifically in the /reload-plugins path (and whatever the VS Code GUI's marketplace-refresh icon calls internally) not invalidating/re-resolving installed plugins — while the dedicated plugin update subcommand's logic is fine. Might be a smaller, more precise fix than a full reinstall-cycle implies: make /reload-plugins (and the GUI refresh action) actually invoke the same update-check claude plugin update already does correctly, instead of only refreshing the marketplace clone.

(Also possibly related, though on a different surface with no CLI escape hatch: #73907, Cowork/Desktop app — same "marketplace refresh succeeds, installed plugin never updates" symptom.)

Confirming this on CLI 2.1.220 (current latest), Windows 11, git-sourced marketplace over HTTPS — and it reproduces on the plain claude plugin … CLI surface, not just the /plugin slash commands, so it isn't specific to the interactive UI or to /reload-plugins.

To answer the "maybe this is intended behavior" question in the original post: the behaviour is consistent with the cache being keyed on the version string. claude plugin update appears to compare versions only, so any content change published without a bump to .claude-plugin/plugin.json is a no-op — which is exactly why the full reinstall is the only thing that works.

Minimal repro with the marketplace clone already fully current (git rev-list --count HEAD..origin/master = 0):

# change plugin content, leave the version alone
echo '<!-- MARKER -->' >> ~/.claude/plugins/marketplaces/<mkt>/standards/some-file.md

claude plugin update <plugin>@<mkt>
# -> "✔ <plugin> is already at the latest version (0.4.2)."

grep -c MARKER ~/.claude/plugins/cache/<mkt>/<plugin>/0.4.2/standards/some-file.md
# -> 0        (never extracted)

"already at the latest version" is the diagnostic: the version matched, so nothing was re-extracted, and the reported success is technically true about the version while being false about the content.

Forced re-extract is the only fix, matching your uninstall → install → reload sequence:

claude plugin uninstall <plugin>@<mkt> && claude plugin install <plugin>@<mkt>

Two things worth adding for whoever picks this up:

1. That workaround has a side effect — the uninstall/install cycle silently drops autoUpdate from the marketplace's extraKnownMarketplaces entry in settings.json. Verified by diffing before/after. So repeatedly applying the workaround progressively disables auto-updating.

1. Verifying by CLI output is unreliable here. Both claude plugin marketplace update and claude plugin update report success on a complete no-op. The only trustworthy check is on the filesystem — compare the extracted cache directory against the marketplace clone directly, rather than trusting exit codes or the version fields in installed_plugins.json.

Closely related: #17361, where I've posted the fuller breakdown separating this from the distinct autoUpdate-never-pulls failure.

Adding a data point that may narrow this down.

On 2026-07-31 I hit this in a form the reinstall workaround did not fix. The marketplace clone was fast-forwarded, /plugin created a NEW cache dir (.../rpg-core/4c2dc00b0da7/), and installed_plugins.json was updated to point at it. /reload-plugins was then run TWICE. The live hooks still executed the OLD cache copy (.../rpg-core/7eb3545a89f2/).

So the pointer was correct and the new files were on disk — the running session just never rebound to them.

What settled it, since "is the new code running?" is otherwise hard to see: the updated file opens a .lock sidecar on every slow-path write. The log it guards sat at exactly its 5000-line cap, so every single write had to take that path. Writes landed after both reloads. No .lock file ever appeared. Old code.

A fresh session picked up the new cache dir immediately, with no further commands.

If that matches your reading, the title may be slightly narrower than the bug: it is not only that marketplace update fails to propagate, but that a running session does not rebind to a new plugin cache directory even when the install succeeded and the pointer is right.

Environment: macOS, plugin installed from a GitHub-backed marketplace.