[BUG] /plugin update does not invalidate plugin cache

is there a workaround until it gets fixed? which files should be removed

+1

@nikitakot Deleting the stale plugin cache resolves the issue:

# Clear cache for a specific marketplace
rm -rf ~/.claude/plugins/cache/<marketplace>/

# Or clear all cached plugins
rm -rf ~/.claude/plugins/cache/

After clearing, restart Claude Code and the plugins will be reinstalled from the updated marketplace repo.

Note: Even with "autoUpdate": true set in ~/.claude/plugins/known_marketplaces.json, the cache is not invalidated when the marketplace repo is updated via git pull.

I'd add that the workaround submitted by the OP doesn't address the entries that remain in ~/.claude/plugins/installed_plugins.json. At least for me, it doesn't appear to cause any error messages, but it also seems that a "clean" update would account for this

This bug is still present in Claude v2.0.74

• I run /plugin
• Select the plugin I want to update
• Click on "Update Now"
• The plugin view disappears, and I see this (no content) message:

<img width="157" height="56" alt="Image" src="https://github.com/user-attachments/assets/dcf75a77-ffa9-4741-923d-4ca49466a053" />

In the meantime, I wrote my own helper script for manually updating plugins using git: update_plugins.py. A preview:

python3 ./helpers/update_plugins.py
🗑️  Deleting cache directory...
   ✅ Cache deleted

🔄 Updating claude-plugins-official...
   ✅ Updated to 6d3752c (main)
🔄 Updating playwright-skill...
   ✅ Updated to bb7e920 (main)
🔄 Updating sablier-plugins...
   ✅ Updated to d31fcec (main)

📝 Updated known_marketplaces.json
📝 Updated installed_plugins.json

✅ All 3 marketplaces updated successfully

We ran into this issue and created a "one and done" solution for our gopher-ai marketplace.

Our approach:

1. git fetch && reset --hard origin/main on the marketplace repo (updates source)
2. Clear the plugin cache (forces reinstall)
3. Remove ALL *@gopher-ai plugin entries from installed_plugins.json using jq

After running, just restart Claude Code - no need to re-add the marketplace. Plugins are automatically reinstalled from the updated marketplace.json.

Key differences from other approaches:

• Uses git reset --hard instead of deleting/re-cloning (always works, even if local diverged)
• Dynamic plugin removal via jq filter - handles renamed/removed/added plugins automatically
• Standard Unix tools only (no Python required)
• Also available as a /refresh-plugins Claude Code command

Script: refresh-plugins.sh

One-liner:

curl -fsSL https://raw.githubusercontent.com/gopherguides/gopher-ai/main/scripts/refresh-plugins.sh | bash

You can adapt this for your own marketplace by changing the marketplace name in the script. The jq filter endswith("@your-marketplace") makes it easy to target any marketplace.

Hope this helps!

+1. It looks like I can only reinstall; the "update" function isn't well yet.

I'm running into _something_ like this where the marketplace is cloned and the cache also contains the plugins, so my hooks are running twice because they exist in two places. Maybe closer to #15621, but maybe same root cause.

I'm running into this issue as I develop local plugins (v2.1.5)

I"m still running into this today on 2.1.29 (Claude Code) on macOS.

same problem here!

same problem here!

I've stopped using Claude plugins. They are buggy. I recommend using npx skills add instead:

npx skills add anthropics/claude-plugins-official

Same thing happens with /reload-plugins. As I understood this feature is supposed to reload the files so that if I change some configuration in ~/.claude/plugins/marketplaces/my-marketplace/my-plugin, it should be reflected in Claude Code without having to restart the session.

As of now, the plugin is always reloaded from the cache so the only way to see the changes is to delete the corresponding folder (~/.claude/plugins/cache/my-plugin)

same. very frustrating for sure.

+1 — /plugin update successfully pulling the repo but not invalidating the cache is the root cause of most of our plugin frustration. The update command should be the single source of truth for 'my plugins are current.'

+1

/reload-plugins and /plugin update aren't functional, even manually clearing cache etc. doesn't work. Each session still separately somehow cache plugins with each session.

the only way to update to latest versions is by full exit and resume which costs tokens and is a difficult feedback loop when developing ad-hoc plugins/mcp-servers/etc.

+1

The bug is real. Confirmed.

Adding a concrete reproduction from a shipping product (CodeVibe, @quantiya/codevibe-claude-plugin on npm).

Our marketplace manifest is hosted on GitHub and pins plugin versions to npm packages via:

{
  "name": "codevibe-claude",
  "version": "1.0.10",
  "source": {
    "source": "npm",
    "package": "@quantiya/codevibe-claude-plugin",
    "version": "1.0.10"
  }
}

Most existing comments here describe the git-based marketplace variant. Our case is a hybrid: git-based manifest that pins npm-based plugin versions, and the bug manifests slightly differently. Reproduced on Claude Code 2.1.101 as of 2026-04-12.

Repro steps:

1. User has codevibe-claude 1.0.5 installed. Filesystem state:

• ~/.claude/plugins/cache/codevibe-marketplace/codevibe-claude/1.0.5/ exists
• installed_plugins.json says "version": "1.0.5", "installPath": ".../1.0.5"

1. We publish 1.0.10 to npm and push updated marketplace.json to GitHub (both version and source.version bumped to 1.0.10).
2. User runs claude plugin marketplace update codevibe-marketplace → succeeds, cached manifest at ~/.claude/plugins/marketplaces/codevibe-marketplace/.claude-plugin/marketplace.json now correctly says 1.0.10.
3. User runs claude plugin update codevibe-claude@codevibe-marketplace → reports:

``
✔ codevibe-claude is already at the latest version (1.0.5).
`
This is factually wrong. The refreshed manifest the command just pulled says 1.0.10. The comparison is being made against the cached plugin's own package.json, not against the marketplace manifest's source.version`.

1. User runs claude plugin install codevibe-claude@codevibe-marketplace → reports ✔ Successfully installed with exit 0. No files change on disk. The mtime on the existing 1.0.5/ directory gets touched and that's it. No 1.0.10/ directory is ever created, no npm fetch happens.
2. User runs claude plugin uninstall codevibe-claude@codevibe-marketplace → removes the entry from installed_plugins.json, but leaves the 1.0.5/ directory on disk. A subsequent install picks it right back up.

The only workaround that works:

claude plugin uninstall codevibe-claude@codevibe-marketplace
rm -rf ~/.claude/plugins/cache/codevibe-marketplace/codevibe-claude
rm -rf ~/.claude/plugins/npm-cache/node_modules/@quantiya/codevibe-claude-plugin
rm -f  ~/.claude/plugins/npm-cache/package-lock.json
claude plugin marketplace update codevibe-marketplace
claude plugin install codevibe-claude@codevibe-marketplace

This creates a fresh 1.0.10/ cache directory and updates installed_plugins.json correctly. All other paths fail silently.

Impact on us as a plugin author: we had to ship a workaround in our own update script (codevibe update) that:

1. Reads installed_plugins.json to get the currently-installed version
2. Reads the just-refreshed marketplace.json to get the expected version
3. If they differ, programmatically rm -rfs the three stale cache paths above and calls claude plugin install
4. Verifies the post-install installed_plugins.json matches the expected version; fails loudly if not

This is ~100 lines of bash that Anthropic's plugin loader should be handling. Without it, customers silently stay on old versions for weeks or months — we saw one customer running a plugin 4 versions behind despite having run codevibe update multiple times. In our case they missed a bug fix for a user-visible mobile sync issue, which shipped weeks earlier to npm but never made it to their cache.

Suggested fix direction (for whoever picks this up): at install time, compare the source.version in the refreshed marketplace manifest against the plugin's own package.json version in the cache directory. If they differ, treat the cache as invalid and force a fresh fetch. At uninstall time, physically remove the cache directory (not just the installed_plugins.json entry). At update time, consult the marketplace manifest as the authoritative "latest version" source, not the cached plugin's own package.json.

Happy to share the cache-healing bash implementation if it's useful for anyone else hitting this until the upstream fix lands.

This is really a important feature that claude code should update.

This is really a important feature that claude code should update.

Confirming this with a repro where the stale cache doesn't just serve old behavior — it makes a component hard-fail to load, which is nastier to diagnose than silent staleness.

Setup: a git-marketplace plugin shipped a fix that removed a malformed line from an agent's frontmatter (a tools: field whose value tokenized into unrecognized tool names, causing the agent to resolve to zero tools). The fix is correct — at repo HEAD the line is gone, and the new version is published.

What the user saw after updating:

• Plugin version metadata advanced to the new version (the plugin manager and reload output both reported it).
• But the cached agent .md under ~/.claude/plugins/cache/ still contained the old, malformed frontmatter.
• Result: spawning the agent failed outright — Agent '…' would be spawned with zero tools — refusing. The agent picker even rendered the broken, tokenized tool list, proving the on-disk cached file was the pre-fix copy.
• /reload-plugins did not help — consistent with the reports here that it only re-reads already-cached files, not the remote.
• Only clearing the cache / reinstalling pulled the corrected files.

So the version-advances-but-content-stays-stale gap isn't only a "you keep running old code" problem — when an update is specifically meant to fix a load-blocking defect, the stale cache keeps the defect in place and the component is unusable until a manual rm -rf ~/.claude/plugins/cache/ + restart. The user reasonably concluded "the latest version didn't fix the bug," when in fact the fix never reached disk.

Two things would each address this:

1. /plugin update (and auto-update) invalidating the cache + updating the stored commit SHA, as this issue asks.
2. A visible "installed version ≠ loaded/cached version" mismatch warning, so this is diagnosable instead of looking like a bad release.

Claude Code 2.x, git-backed marketplace, macOS.