Git Worktree Branch Locked by "Already Checked Out": Local, Linked, and Remote-Tracking Fixes (2026)

Published February 28, 2026 · 8 min read

Next Step

Validate what changed before removing or reattaching worktrees

Use a real diff check before branch ownership moves so cleanup does not hide uncommitted or rewritten changes.

Open Git Diff Viewer

If Git reports fatal: '<branch>' is already checked out at '<path>', do not force checkout blindly. The fix depends on which state you are in: local branch ownership conflict, stale/active linked worktree, or a remote-tracking workflow mismatch.

Fast triage command block

git worktree list --porcelain

git branch -vv

git status --short

These three commands tell you who owns the branch, what path is attached, and whether you have local changes to protect.

Decision path by failure type

Case	Signal	Correct action
Local-branch conflict	Error references an existing branch you are trying to reuse in a second directory.	Keep one branch per active worktree. Either remove the old worktree safely or create a new branch name for the new worktree.
Linked-worktree conflict	Error points to a path that is missing, moved, or no longer valid.	Run `git worktree prune`, then verify with `git worktree list --porcelain` before re-running add/checkout.
Remote-tracking mismatch	You are trying to bind a local branch name that is already owned while adding from `origin/<branch>`.	Use detached checkout for inspection, or create a distinct local branch name with explicit tracking instead of reusing the locked branch name.

1. Local-branch case: branch already owned by another worktree

# inspect owner path
 git worktree list --porcelain

# if old path is no longer needed and clean
 git worktree remove /path/to/old-worktree

# then create or attach safely
 git worktree add ../new-worktree your-branch

Never remove a worktree until you confirm whether it has uncommitted edits. Capture a patch or commit first if status is not clean.

2. Linked-worktree case: stale metadata points to dead path

git worktree prune

git worktree list --porcelain

git worktree add ../recreated-worktree your-branch

This is the safe recovery path when someone deleted the worktree folder directly from the filesystem.

3. Remote-tracking case: origin branch exists, local branch name is locked

# Option A: inspect remote branch without claiming local branch ownership
 git worktree add --detach ../inspect-origin-feature origin/feature

# Option B: create a new local tracking branch name
 git worktree add -b feature-recovery ../feature-recovery --track origin/feature

Remote-tracking branches do not require reusing the same local branch identifier in every worktree. Naming a distinct local branch is usually safer during incident recovery.

Related recovery paths:

FAQ

Can I use one branch in two worktrees at the same time?

No. Git enforces single ownership for a branch across active worktrees.

When should I use `--detach` with worktree add?

Use it when you need a temporary inspection workspace from a remote-tracking ref without taking ownership of an existing local branch name.

What if commits seem missing after cleanup?

Use git reflog --date=iso --all in the main repo and recover by SHA before continuing cleanup.