Support version pinning in plugin install command

Status Open

Maintainer reply ✓ Yes — stbenjam

Activity 4 comments · opened May 30, 2026

💡 Likely answer: A maintainer (stbenjam, contributor) responded on this thread — see the highlighted reply below.

Summary

Recently, Claude Code has a way to [tag versions of plugins]( https://code.claude.com/docs/en/plugin-dependencies#tag-plugin-releases-for-version-resolution).

However, this feature only seems to be half implemented. It is only used for dependency resolution. It is neither supported by the plugin install command, or in settings.json. Users should be able to opt in to specific versions of a plugin, not just through dependency management.

claude plugin install <plugin>@<marketplace> has no way to specify a version. The version resolution engine (semver ranges, git tag enumeration via {name}--v{version}, maxSatisfying) exists and works, but is only reachable through the inter-plugin dependency resolution path.

Current behavior

install <plugin>
  -s, --scope <scope>          # user, project, or local
  --config <key=value>         # plugin manifest config

Always installs whatever the marketplace catalog currently points to. No --version flag.

Requested behavior

claude plugin install secrets-vault@acme-tools --version "~2.1.0"

or inline syntax like:

claude plugin install secrets-vault@acme-tools@2.1.0

This would let users pin a plugin to a specific version or semver range, using the same tag resolution logic that already exists for dependency constraints.

It should also be accessible in settings.json.

Workarounds

Pin the entire marketplace to a git ref (/plugin marketplace add repo.git#v1.0.0) — freezes all plugins, not just one
Disable auto-update after install — prevents upgrades but doesn't control which version you initially get

Context

The plugin dependency versioning docs describe a full version resolution system: {name}--v{version} git tags, semver range constraints (~2.1.0, ^2.0, >=1.4, =2.1.0), and intersection of multiple constraints. All of this machinery exists in the codebase but is not exposed to end users via the install command.

---

_Re-filed from #62446 which was closed as duplicate._. There are no open duplicates of this issue.

View original on GitHub ↗

3 Comments

kaltinril · 2 months ago

Yes, I second this. I tried out plugins but they are useless for me with a team because the version pin is in my home directory and not in the PROJECT directory settings.json

My 2 cents

Plugin install state (version, install path) lives in ~/.claude/plugins/installed_plugins.json — per-machine, not committed. Project-scope installs write only enabledPlugins: ["name@marketplace"] to .claude/settings.json, with no version. With official-marketplace auto-update on by default, a fresh clone (or the same dev over time) silently resolves to the latest plugin version, not the one the project was built/tested against.

Impact: No reproducibility across a team or over time. Two people on the same commit can run different plugin versions, with different agents/skills/hooks/MCP behavior.

ondrejtucny · 1 month ago

Yes, this is absolutely necessary. Version pinning must be supported in the project-level settings.json. It's critical for reliable and consistent team-wide experience and controlled rollouts of new plugin versions.

Consider multiple repositories, each structured and configured (e.g. via CLAUDE.md or other docs) to work well with a _different_ version of the same plugin. Repos which depend on an older version of a plugin just cannot be auto-upgraded to a newer version on a per-developer basis! In a team on a large project, in an environment with tens, hundreds or thousands of repos this lack of basic governance hinders Claude Code adoption significantly.

stbenjam contributor · 1 month ago

This is still needed. Commenting to keep this alive since the bot is very aggressive in closing.

Showing cached comments. Read the full discussion on GitHub ↗