Skip to content

git gtr clean: could detect and recover locked-but-missing worktree entries #180

Description

@echarrod

Summary

When Claude Code's agent isolation creates worktrees under .claude/worktrees/agent-<hash>, it marks them as locked (a .lock file in .git/worktrees/<name>/). If the agent session ends abruptly — crash, interrupt, OOM — the worktree directory gets deleted but the git registry entry remains, still locked.

Running git gtr clean --merged --yes --force then fails silently for these entries: the preRm hook bails because the directory no longer exists, so the entries are skipped. A subsequent git branch -D <branch> then fails with:

error: cannot delete branch 'ed-CPB-1244-...' used by worktree at '/…/.claude/worktrees/agent-abc123'

because git still considers the branch checked out in the phantom worktree.

git worktree prune alone won't fix it — it skips locked entries by design.

Recovery (manual)

git worktree unlock .claude/worktrees/agent-<hash>
git worktree prune -v
git branch -D <branch>

Possible improvement

It might be worth git gtr clean detecting this condition: if a worktree's directory no longer exists and its registry entry is locked, it could:

  • Auto-unlock + prune rather than bailing, or
  • At minimum, surface the recovery command in the error output.

Not certain whether this is squarely in scope for gtr — it may partly be a Claude Code agent cleanup gap — but raising it in case it's a useful addition.

Happy to look at a PR if the approach seems right.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions