[BUG] /reload-plugins errors on every plugin from a marketplace whose checkout updated ahead of installed versions; retrying never heals

Status Open
Reported on v2.1.222
Maintainer reply None cached
Activity 0 comments · opened Aug 5, 2026

Summary

When a git-source marketplace's checkout auto-updates to a state where the catalog's plugin versions no longer match the installed versions, /reload-plugins fails with one error per installed plugin from that marketplace ("N errors during load. Run /plugin for details") — and re-running /reload-plugins can never heal it, because the reload never (re)installs the missing plugin versions. The broken state persists across sessions for hours until an unrelated background auto-update pass re-clones the marketplace and reinstalls the plugins, at which point reload works again. To the user this looks like the marketplace randomly breaking and randomly fixing itself.

Environment

  • Claude Code 2.1.222, macOS (darwin 25.5.0)
  • A git-source marketplace (known_marketplaces.json entry with "source": "git", "autoUpdate": true) hosted on an internal GitLab
  • 11 plugins installed from it at user scope
  • The marketplace is CI-rendered: every commit to the source repo republishes the catalog with every plugin's version field stamped to the new commit SHA (so any publish invalidates all installed plugins at once — this makes the window easy to hit, but the underlying behavior would apply to any version bump)

What happens (observed timeline, times UTC)

  1. 20:32 — auto-update installs all 11 plugins at marketplace version A (installed_plugins.json entries point at ~/.claude/plugins/cache/<marketplace>/<plugin>/<A>). Everything healthy.
  2. 22:22 — a new render (version B) is published to the marketplace repo.
  3. Next session start (00:14:45) — the marketplace checkout under ~/.claude/plugins/marketplaces/<name> is updated to B (known_marketplaces.json lastUpdated bumps), but the installed plugins are not reinstalled: installed_plugins.json still points at A, and no cache directories for B exist.
  4. /reload-pluginsReloaded: 5 plugins · 0 skills · … 11 errors during load. The 11 errors are exactly the 11 plugins from this marketplace. Running /reload-plugins again — same session or a fresh one, hours apart — reproduces the same 11 errors every time.
  5. 00:19:00 — a background auto-update pass (triggered by an unrelated headless claude -p run) freshly re-clones the marketplace (its reflog shows a single clone: entry) and reinstalls all 11 plugins at B within the same second (installed_plugins.json lastUpdated stamps 00:19:00.7).
  6. /reload-plugins → clean (16 plugins · 6 skills · …, no errors).

So the failure window is: marketplace checkout updated eagerly at session startplugin reinstall happens lazily on some separate, infrequent trigger → in between, every reload errors and cannot self-repair.

Expected behavior

Any of these would fix the user-facing problem:

  • /reload-plugins installs the missing plugin version when the marketplace catalog references a version that has no cache directory (it clearly knows the plugin is stale — that's the error), or
  • it falls back to loading the installed/cached version and reports "update pending" instead of a hard per-plugin error, or
  • session start doesn't update the marketplace checkout without also reconciling installed plugins in the same pass (updating the catalog eagerly while installing lazily is what manufactures the mismatch).

Workaround

claude plugin update <plugin> (or waiting for a background auto-update pass) reinstalls at the new version and clears the errors. Nothing in the /plugin UI or the reload output points the user at this; repeated reloads — the natural response to the error — never help.

Notes

  • The error detail in /plugin for each affected plugin corresponds to the install path for the marketplace's current version not existing on disk.
  • Marketplaces that stamp per-commit versions across all plugins make this near-permanent for active repos (every merge reopens the window for every installed plugin), but the same mismatch should reproduce with any single plugin whose catalog version is bumped between the checkout update and the reinstall pass.

View original on GitHub ↗