plugin install fails for git-subdir sources pinned to a commit SHA ("fatal: Remote branch <sha> not found in upstream origin")

Summary

claude plugin install <plugin>@<marketplace> fails for any git-subdir source whose manifest ref is a commit SHA that is not the tip of a branch or tag. The installer shells out to git clone --branch <ref> <url>, and git clone --branch can only resolve branch/tag names — never an arbitrary (even fully valid, reachable) commit SHA. This makes SHA-pinned git-subdir refs — which Anthropic's own documented git-subdir schema (referenced from plugin schema Issue #107 by downstream marketplace authors) does not disallow — unusable in practice.

This blocks 100% of installs from any marketplace that pins ref to a commit SHA, regardless of which plugin/skill is selected.

Environment

• claude --version: 2.1.197 (Claude Code)
• git --version: git version 2.50.1 (Apple Git-155)
• OS: macOS (Darwin 25.5.0)
• Marketplace under test: liatrio-skills (source: github:liatrio-labs/skills), added via extraKnownMarketplaces / claude plugin marketplace add

Steps to reproduce

1. Add a marketplace whose .claude-plugin/marketplace.json pins a plugin's source.ref to a 40-character commit SHA that is not currently a branch or tag tip, e.g.:

``json
{
"name": "brain-storm",
"source": {
"source": "git-subdir",
"url": "https://github.com/liatrio-labs/skills.git",
"path": "skills/brain-storm",
"ref": "49985c9e5e5f8503100989ac3ae223864a062982"
}
}
``

1. Run:

``
claude plugin install brain-storm@liatrio-skills
``

Actual result

Installing plugin "brain-storm@liatrio-skills"...
✘ Failed to install plugin "brain-storm@liatrio-skills": Failed to clone repository for git-subdir source: Cloning into '/Users/amberbeasley/.claude/plugins/cache/temp_subdir_1784756861187_6nlafe.clone'...
fatal: Remote branch 49985c9e5e5f8503100989ac3ae223864a062982 not found in upstream origin

Same failure is reproduced through the interactive /plugin → Discover → Install flow (not just the claude plugin install CLI form).

We also confirmed this is not a stale-cache issue: running claude plugin marketplace update liatrio-skills first (which fetched a newer manifest with a different pinned SHA) did not change the outcome — the second, freshly-updated SHA failed with the identical error class.

Expected result

The plugin installs successfully. A commit SHA is a legitimate, fully resolvable git object reference; a git-subdir source pinned to a SHA should be installable, since pinning to an exact commit (rather than a mutable branch/tag) is a reasonable and arguably more secure practice for supply-chain integrity.

Root cause

Isolated the failure to plain git, independent of Claude Code entirely:

$ git clone --branch 49985c9e5e5f8503100989ac3ae223864a062982 https://github.com/liatrio-labs/skills.git
Cloning into 'sha-clone-test'...
fatal: Remote branch 49985c9e5e5f8503100989ac3ae223864a062982 not found in upstream origin

git clone --branch <ref> is documented to only accept a branch or tag name (it does a single-branch/shallow clone against an advertised ref) — it cannot check out an arbitrary commit SHA even when that SHA is valid and reachable on the remote.

Proved the SHA itself is legitimate and reachable — a full clone followed by an explicit checkout succeeds without issue:

$ git clone https://github.com/liatrio-labs/skills.git sha-clone-test2
Cloning into 'sha-clone-test2'...
...
$ git -C sha-clone-test2 checkout 49985c9e5e5f8503100989ac3ae223864a062982
Note: switching to '49985c9e5e5f8503100989ac3ae223864a062982'.
...
HEAD is now at 49985c9 feat: onboard grill-with-docs, wayfinder, and thermo-nuclear-code-quality-review skills (#203)

So: the commit exists, is reachable, and checks out cleanly — the only broken step is the installer's use of git clone --branch <ref> to resolve it.

Suggested fix

For git-subdir sources, when ref does not resolve as a branch/tag via the initial --branch clone, fall back to (or always use) a resolve-by-SHA path, e.g.:

git init <dest>
git -C <dest> remote add origin <url>
git -C <dest> fetch --depth 1 origin <ref>
git -C <dest> checkout FETCH_HEAD

GitHub (and most modern git servers) advertise uploadpack.allowReachableSHA1InWant / allowTipSHA1InWant, so git fetch origin <sha> generally succeeds directly against a bare commit SHA without needing a full clone. This would make SHA-pinned git-subdir refs work as intended while preserving shallow-fetch performance.

Additional impact

Because this blocks the plugin-install path outright, skills from affected marketplaces can only be installed through side-channel installers (e.g. the skills.sh CLI, which symlinks into ~/.claude/skills directly). Those side-channel installs are invisible to Claude Code's own plugin registry (~/.claude/plugins/installed_plugins.json stays empty), which means the plugin.name / marketplace.name OpenTelemetry attributes on the claude_code.skill_activated event (see Monitoring usage) never populate for these skills, since those attributes are only emitted "when the skill is provided by a plugin." Org telemetry dashboards (e.g. Honeycomb boards keyed on marketplace.name) built against the documented attribute silently show zero data for any marketplace that hits this bug — with no error surfaced anywhere to explain why.

Reference

• Marketplace manifest in question: liatrio-labs/skills → .claude-plugin/marketplace.json
• Their internal spec mandating SHA-only refs as a security control (predates discovery of this incompatibility): docs/specs/15-spec-marketplace-manifest-schema/15-spec-marketplace-manifest-schema.md