[BUG] Stale .git/index.lock left behind after Bash tool git commands on Windows

Also reproducible on Linux (WSL2) with git worktrees

This is not Windows-specific. Same root cause as the original #11005 — CC's background git status polling races with foreground git commands.

Environment

• Claude Code: 2.1.58
• Platform: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
• Git: worktree setup (main repo + multiple linked worktrees)

Repro

1. Open Claude Code in a git worktree directory
2. Ask CC to run a git command that touches the index (e.g., git reset --hard <ref>)
3. The command fails with Unable to create '.git/worktrees/<name>/index.lock': File exists
4. fuser confirms no process holds the lock — it's stale
5. Remove the lock manually, retry — same failure. CC's background polling re-creates the lock between rm and the git command in the same && chain
6. Only works if rm and the git command run in separate Bash tool invocations with enough time gap that CC's polling cycle isn't active

Key detail: worktree lock path

With worktrees, the lock path is .git/worktrees/<name>/index.lock (not .git/index.lock), so worktree-unaware cleanup logic won't find it.

Suggestion

CC's internal git status --porcelain polling should use --no-optional-locks (as one commenter on #11005 suggested for statusline scripts). This flag was added to git specifically for monitoring tools that shouldn't contend with interactive commands.

Today, it just can't do anything without having to force remove git locks. I wonder if this is a worktree issue? Claude and manually created worktrees are pretty rough these days :(

This has definitely been reported, and it was closed for some weird reason. It's extremely annoying and constantly asking me to delete index.lock...

https://github.com/anthropics/claude-code/issues/11005

I'm on MacOS M4 Tahoe 26.2

Not specific to Windows. It's CC doing something that causes a lock and kills the agentic loop with delete permissions.

Yeah, it also loves to blame it on some rogue "VS Code extension" running somewhere. So frustrating.

This has become common error for me and I have been asking clause to ignore give another try and it happily succeeds. Looks like a race within the bash script called by Claude as I literally don't have any other session open and doing same activities at the same time.

Error: Exit code 128
     fatal: Unable to create '<path>/.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.

     fatal: Unable to create '<path>/.git/index.lock': File exists.

Also happening here on Ubuntu 24.04

Infuriating

Happens on macos, very very painfull

Fixed on my end by updating the statusline to use git status --porcelain

Fixed on my end by updating the statusline to use git status --porcelain

This ^

My statusline script was conflicting with my commands. I had a command to check if repo was dirty (uncommitted files). I added --no-optional-locks and the problem was gone.

 47 -    dirty=$(git -C "$cwd" status --porcelain 2>/dev/null)                                                                                                                                
 47 +    dirty=$(git -C "$cwd" --no-optional-locks status --porcelain 2>/dev/null)  

A PostToolUse hook can automatically clean up stale lock files after git commands:

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
echo "$COMMAND" | grep -qE '\bgit\b' || exit 0
GIT_DIR=$(git rev-parse --git-dir 2>/dev/null) || exit 0
LOCK="$GIT_DIR/index.lock"
[ -f "$LOCK" ] || exit 0
if ! pgrep -x git > /dev/null 2>&1; then
    rm -f "$LOCK" 2>/dev/null
    echo "INFO: Removed stale .git/index.lock" >&2
fi
exit 0

Settings:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/git-index-lock-cleanup.sh"}]
    }]
  }
}

This runs after every Bash git command, checks if .git/index.lock exists with no running git process, and removes it. Won't interfere with legitimate locks from concurrent git operations.

Additional data: 10-second internal polling confirmed via FileSystemWatcher

I'm seeing this on Windows 10 Pro, Claude Desktop v1.1617.0, with no custom statusline script configured. The polling is coming from Claude Code's internal harness, not a user statusline.

Exact timing evidence

Used a PowerShell FileSystemWatcher on .git/worktrees/<name>/ to monitor index.lock creation/deletion with no git commands running:

Detected 6 lock events in 60 seconds:
  18:56:16.757
  18:56:26.797 (gap: 10.0s)
  18:56:36.776 (gap: 10.0s)
  18:56:46.762 (gap: 10.0s)
  18:56:56.758 (gap: 10.0s)
  18:57:06.761 (gap: 10.0s)

Each lock file exists for ~6ms. The 10-second interval is exact and consistent.

Confirmed: only the active worktree is polled

Monitored four locations simultaneously for 20 seconds:

• .git/worktrees/upbeat-rosalind/ — 2 hits
• .git/worktrees/admiring-beaver/ — 0 hits
• .git/worktrees/cool-blackwell/ — 0 hits
• .git/ (main repo) — 0 hits

Only the worktree for the active Claude Code session is polled.

Environment

• Windows 10 Pro 10.0.19045
• Claude Desktop v1.1617.0 (Electron)
• 46 git worktrees sharing one .git directory
• No custom statusline configured in settings
• Git 2.47.1.windows.2

Workaround

Built a bash retry wrapper that detects index.lock errors, removes the stale lock via PowerShell (bash rm often fails on Windows for these transient files), and retries. Works reliably.

The proper fix would be for Claude Code's internal polling to use git --no-optional-locks status --porcelain instead of git status --porcelain.

Thanks for the script yurukusa but I still had issues.

I restored my workaround in ~/.claude/CLAUDE.md:

## Git (local)

- Prefix git commands that write to the local `.git/` directory with `sleep 0.1 && ` to avoid
  `.git/index.lock` contention. Claude MUST add this prefix ONLY to such commands.
  If the write fails on `.git/index.lock`, retry once after 0.5s.
  - Needs prefix: `git commit`, `git add`, `git push`, `git checkout`, `git fetch`, `git rebase`, 
    `git reset`, `gh stack init`, `gh stack submit`, `gh pr checkout`
  - No prefix: read-only git/gh (`git status`, `git log`, `git diff`, `gh api`, `gh pr view`, `gh`), 
    GitHub API writes that don't touch local `.git/` (`gh pr create`, `gh pr edit`, `gh pr comment`,
    `gh pr merge`), any non-git command (`grep`, `find`, `docker`, etc.)

There are workarounds for the workaround because Claude randomly added sleep 0.1 && to other commands. 🫠

My statusline script was conflicting with my commands. I had a command to check if repo was dirty (uncommitted files). I added --no-optional-locks and the problem was gone. 47 - dirty=$(git -C "$cwd" status --porcelain 2>/dev/null) 47 + dirty=$(git -C "$cwd" --no-optional-locks status --porcelain 2>/dev/null)

Nice, thanks! Claude suggested export GIT_OPTIONAL_LOCKS=0 instead, because it was easier to alter the 5 git calls.