[BUG] Plugin install fails for git-subdir sources since 2.1.274: "git checkout after sparse-checkout failed … index.lock: File exists"

Status Open
Reported on v2.1.274
Maintainer reply None cached
Activity 1 comment · opened Oct 1, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Since 2.1.274, installing or updating any plugin whose marketplace source is "git-subdir" fails with an index.lock error.

The lock message is misleading: there is no concurrent git process and no stale lock from an earlier run.

  1. The installer makes a treeless clone (--filter=tree:0 --no-checkout), applies a cone sparse-checkout, then runs git checkout HEAD with

lazy fetching disabled.

  1. A treeless clone has no tree objects locally and the checkout is not allowed to fetch them. On git 2.34.1 this checkout segfaults (exit

139) and leaves a 0-byte .git/index.lock.

  1. The installer then retries git checkout HEAD, which fails on that stale lock. Only the retry's error is shown.

Regression window (same claude plugin install, each version run through npx in an isolated CLAUDE_CONFIG_DIR):

  • 2.1.273: works
  • 2.1.274: fails (first failing version)
  • 2.1.275 to 2.1.278: fail
  • 2.1.286 (latest): fails

Probably the same change as #96134 (same window, there the lazy fetch is rejected for http transport). That issue is closed, but this case
still fails on 2.1.286.

Environment: Ubuntu 22.04.5 LTS, git 1:2.34.1-1ubuntu1.17, Claude Code installed with npm.
Not specific to SSH: the public HTTPS repro below shows the same failure.

Workaround: npx -y @anthropic-ai/claude-code@2.1.273 plugin install <plugin>@<marketplace> --scope user

What Should Happen?

The plugin installs. The checkout should be allowed to fetch the trees and blobs the sparse cone needs (or fetch them explicitly before
checking out with lazy fetch disabled).
If the first checkout fails, Claude Code should report that error, not the retry's misleading index.lock error.

Error Messages/Logs

Failed to install: git checkout after sparse-checkout failed: fatal: Unable to create
  '/home/<user>/.claude/plugins/cache/temp_subdir_1790840678532_5dc4d7.clone/.git/index.lock': File exists.

  Another git process seems to be running in this repository, e.g.
  an editor opened by 'git commit'. Please make sure all processes
  are terminated then try again. If it still fails, a git process
  may have crashed in this repository earlier:
  remove the file manually to continue.

  Underlying first failure, reproduced by hand:
  warning: lazy fetching disabled; some objects may not be available
  Segmentation fault (core dumped)   GIT_NO_LAZY_FETCH=1 git checkout HEAD   -> exit 139, 0-byte .git/index.lock left behind

Steps to Reproduce

In Claude Code:

  1. Add a marketplace with a plugin whose source is {"source": "git-subdir", "url": "...", "path": "<subdir>", "ref": "master"}
  2. Run: claude plugin install <plugin>@<marketplace> --scope user
  3. It fails with the index.lock error above. With 2.1.273 the same command succeeds:

npx -y @anthropic-ai/claude-code@2.1.273 plugin install <plugin>@<marketplace> --scope user

Outside Claude Code (public repo, git 2.34.1):
git clone -q --depth 1 --filter=tree:0 --no-checkout https://github.com/anthropics/claude-code.git repo
cd repo
git sparse-checkout set --cone plugins
GIT_NO_LAZY_FETCH=1 git checkout HEAD; echo "RC=$?" # Segmentation fault, RC=139, leaves 0-byte .git/index.lock
rm .git/index.lock
git checkout HEAD; echo "RC=$?" # lazy fetch allowed: RC=0, files checked out

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.273

Claude Code Version

2.1.286

Platform

AWS Bedrock

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

What was ruled out:

  • Not a stale lock: every attempt uses a fresh temp_subdir_*.clone directory, and deleting the lock doesn't help because the next attempt

crashes and creates it again.

  • Not SSH or auth: the SSH agent is running, the clone itself succeeds, and the public HTTPS repro fails the same way.
  • Not git config: ~/.gitconfig has no fetch, partial-clone or sparse settings, and there is no system gitconfig.
  • Not a git upgrade: git was last upgraded in February 2026, and installs/updates were still succeeding on 2026-09-16 with that same git.

Impact:

  • It affects every git-subdir plugin in a marketplace (32 plugins in ours), on both install and update.
  • Already-installed plugins keep working but can't be updated on 2.1.274 or later.
  • Plugins installed with the 2.1.273 workaround are recorded correctly (gitCommitSha matches the remote ref) and load fine in 2.1.286.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗