claude-code - 💡(How to fix) Fix [UX] /plugin install on an already-installed plugin does not refresh stale cache, leaving users on outdated versions

Summary

When a user has a plugin installed from before a major upstream update, running /plugin install <plugin>@<marketplace> again returns Plugin '...' is already installed globally. Use '/plugin' to manage existing plugins. and does not refresh the cached implementation. The user remains on the pre-update version indefinitely — even if the marketplace catalog has the new files locally available.

The user has no obvious way to discover this. From the surface (/plugins Installed tab), the plugin looks correctly installed and enabled. Hooks may silently fail or behave differently than the documentation describes, with no error indicating that the cached code is stale.

Concrete case I hit (verified 2026-05-28)

• Environment: Windows 11, Claude Code v2.1.153, user home path contains a space (C:\Users\First Last\).
• Plugin: security-guidance@claude-plugins-official.
• Original install: Some time before 2026-04-21 (under the older plugin layout — single PreToolUse hook, no sg-python.sh launcher, unquoted ${CLAUDE_PLUGIN_ROOT} in the hook command).
• Today: Marketplace catalog (~/.claude/plugins/marketplaces/claude-plugins-official/plugins/security-guidance/) has v2.0.0 files dated 2026-05-28 with the new sg-python.sh launcher and properly quoted commands. But cache (~/.claude/plugins/cache/claude-plugins-official/security-guidance/unknown/) is still the 2026-04-20 layout, and that is what Claude Code loads.

What I observed

1. /plugin install security-guidance@claude-plugins-official →

   Plugin 'security-guidance@claude-plugins-official' is already installed globally.
   Use '/plugin' to manage existing plugins.

2. /plugins Installed tab shows the plugin as installed (and after enable, ✓ enabled).
3. /plugins Errors tab: No plugin errors.
4. Triggering an Edit/Write of code containing os.system(x) produces no security warning — silent.
5. Inspection of the cache directory shows files dated 2026-04-20 with the old (broken-on-Windows) hook layout.
6. The marketplace directory has v2.0.0 files dated 2026-05-28 with all the Windows-aware fixes baked in.

What fixed it

• /plugin uninstall security-guidance@claude-plugins-official (via the /plugins UI)
• /plugin install security-guidance@claude-plugins-official
• /reload-plugins

After these three steps, the cache directory has a new 2.0.0/ subdir alongside the old unknown/ (which now carries an .orphaned_at marker), the new launcher runs, and the security warning fires correctly on os.system(x).

Why this is a problem

1. Silent staleness: A user who installed the plugin pre-update and runs /plugin install to "make sure they have the latest" sees a friendly success-ish message and reasonably assumes they're current. They're not.
2. The Errors tab does not help: Hook execution failures in the stale version are not classified as plugin errors (presumably because they're stderr from spawned processes, not parsed-config errors). Users have no breadcrumb that anything is wrong.
3. Particularly bad for security plugins: For security-guidance specifically, a user believes Anthropic's official security plugin is protecting them while it is silently doing nothing. That is arguably worse than no plugin at all.
4. Affects exactly the users a plugin author wants to fix: A v2.0.0 release exists precisely because v1 had issues. Users with the longest-standing installs are the most likely to be hit by those issues, and they are exactly the population that doesn't get the fix.

Suggested fix (one or more)

In rough order of effort:

1. /plugin install on an already-installed plugin should compare cached version against the marketplace catalog and re-fetch if different. Print a clear message: Updated security-guidance from <old-version> to <new-version>. Run /reload-plugins to apply.
2. A dedicated /plugin update <name> (or /plugin update --all) command. Same outcome, but explicit.
3. A periodic auto-update check on Claude Code startup or session-start, surfacing a one-line nudge: 1 plugin update available — run /plugin update to refresh.
4. At minimum, change the current "already installed" message to point users at the right escape hatch: Plugin '...' is already installed globally (cached version: <X>, marketplace version: <Y>). Run /plugin uninstall && /plugin install to refresh, or /plugin update <name> if you only want to update.

(1) and (4) are probably the smallest wins.

Possibly related signal

The cache directory layout in this case includes an unknown/ subdirectory rather than a versioned one (e.g., 2.0.0/). The presence of unknown may indicate that the original install lacked version metadata, and the cache loader does not know how to compare it to the marketplace's current version. If /plugin install checked for the existence of any cache subdir other than the marketplace's current version and re-fetched in that case, this specific instance would be handled.

Not part of this report

The underlying Windows space-path bug in the old security-guidance hook (unquoted ${CLAUDE_PLUGIN_ROOT} → shell split → script not found) has been fully fixed in the v2.0.0 release via sg-python.sh and proper quoting in hooks.json. That part is great work, thank you. This report is purely about the delivery channel: users not getting the fix unless they happen to uninstall/install.