fix(worktree): guard a registered path that no longer holds its worktree

[max-sixty]

A registered worktree's path was trusted to still hold that worktree. Three defects followed, one of them destroying data, and the check that would have caught them — where it existed at all — was Path::exists().

wt remove --force deleted an unrelated repository

A clone that came to sit at a stale registration's path was removed whole, including uncommitted work and, for a repo never pushed, the only copy of its objects. wt's own hint routed the user there: the dirty gate reads git status in that directory, reports the occupant's changes as this worktree's, and offers --force as the cure.

$ wt remove feature
✗ Cannot remove worktree: feature has uncommitted changes
  ?? precious.txt                                          # ← the other repo's file
↳ ... to lose uncommitted changes, run wt remove --force feature

git refuses that same removal, --force included (validation failed … is not a .git file). Worktrunk's fast path renames the directory into trash rather than asking git to, so git's validation never ran. ensure_belongs_to_repo makes it, comparing the directory's git dir against this repository's: a linked worktree's sits under <common>/worktrees/, the main worktree's is the common dir, anything else answers to someone else. One comparison covers both worktree kinds and also rejects a .git file pointing at another repo, which git's shape test accepts.

It runs at planning, ahead of the dirty gate, and again at the rename for callers that stage without planning. Now:

$ wt remove --force feature
✗ Directory @ ../repo.feature is not this repository's worktree
↳ Removing it could destroy unrelated data; move the directory aside, then run git worktree prune

A recreated worktree directory leaked git's exit 128

wt switch, wt merge, and wt step push walked into git rev-parse --git-dir failed (exit 128). Two of them probed Path::exists() first, which a deleted-and-recreated directory passes; the third asked nothing.

worktree_is_unusable is the union of both tests, because neither implies the other. exists() catches the absent directory; git's prunable catches the recreated one. prunable alone is not the wider test it looks like — git withholds the attribute from a locked worktree even when its directory is gone, since prunability is its pruning policy and a lock means "don't prune this":

$ git worktree list --porcelain          # wt2 locked, all three directories removed
worktree /tmp/ptest/wt1
prunable gitdir file points to non-existent location
worktree /tmp/ptest/wt2
locked removable media                   # ← no prunable line
worktree /tmp/ptest/wt3
prunable gitdir file points to non-existent location

A locked worktree on an unmounted volume is exactly what prepare_worktree_removal's lock guard exists for, so a prunable-only test would read it as healthy. All three commands now give the message the merely-deleted case already gave.

wt remove keeps exists(), deliberately: there it is the precondition for the cleanup path rather than a health test, since prune_worktree_entry unregisters via git worktree remove, which skips validation only while the directory is absent. No scoped git command clears the recreated case, so it reports and names the repo-wide git worktree prune that does.

wt switch docs/ missed a branch sitting right there

Git's ref format forbids a trailing /, so the branch lookup never had a candidate — and shell completion produces exactly that spelling whenever a docs directory sits beside the branch. Selectors are normalized before resolution.

Resolving selectors through one ladder

The three fixes landed in three of the four places that assemble "expand shortcuts, try the branch, try the path, classify the failure" by hand. Each gated its path attempt on "did something rewrite this token?", answered by comparing an expansion's output against its input:

where	the comparison
resolve_worktree	branch == name
plan_switch	target.branch == branch
target_worktree_at_path	target.filter(|t| *t == resolved)
resolve_base_ref	resolved == base

That is a fact the rewriting step knows, re-derived downstream from its output, and it is wrong in both directions. A shortcut can expand to the token it was given — - pointing at the branch you are already on — and string equality reads that as a literal, turning the path arm back on for a token nobody typed. Normalization breaks it the other way, which is why the trailing-separator fix needed threading through three call sites.

Selector carries the fact instead: expand_shortcut reports whether it fired, wt switch reports its pr:/mr: dispatch and remote-prefix strip, and names_a_path() replaces all four comparisons. resolve_selector is the ladder, and plan_switch expands into it rather than re-implementing its phases.

names_a_path() gates both path steps together — the worktree-by-path lookup and the directory verdict — which is what wt switch --create needs: the argument names a branch to create, so branch_only() takes the arm off at the producer rather than each consumer re-testing create.

It also reaches the directory verdict, so ResolvedWorktree gains NoWorktreeAtPath and the four sites that called path_selector_error themselves stop re-deriving it. The docstring defending that laziness didn't survive checking — the function returns on is_valid_branch_name before touching the filesystem, so every ordinary branch name already short-circuited.

	before	after
normalize_selector call sites	3	1
path_selector_* call sites	4	2
"was it rewritten?" comparisons	4	0

Navigating the diff

• src/git/repository/mod.rs — Selector, normalize_selector, the new ResolvedWorktree variant.
• src/git/repository/worktrees.rs — expand_shortcut, expand_selector, resolve_selector, usable_worktree_for_branch.
• src/git/repository/working_tree.rs — ensure_belongs_to_repo, the ownership check.
• src/git/remove.rs, src/commands/repository_ext.rs — where it gates removal, and why before the dirty gate.
• Call sites: commands/worktree/switch.rs, commands/worktree/push.rs, commands/merge.rs, commands/remove.rs, git/repository/config.rs.

Size

Comments and docstrings are the largest share: the ownership check and the four conditions behind the directory verdict all look like things to simplify away, so the reason each exists is recorded where it's enforced.

	+	−
Production code	277	142
Comments & docstrings	320	75
Tests	325	8
Snapshots	186	0
Docs	6	0
Total	1114	225

Testing

Seven new tests. The data-safety one drives the real binary and asserts the filesystem afterwards, not just the exit code — removal stages by rename and deletes in a detached process, so a passing exit would not have caught a staged-then-deleted tree. The others cover the recreated directory (switch and remove), the trailing separator, --create against a worktree registered at that path, and, at the unit boundary, the four states of worktree_is_unusable — healthy, absent, locked-and-absent, recreated — and the selector's path-ness, including the degenerate case string equality got wrong. Each new test was confirmed to fail with its fix reverted.

One more covers an omitted merge target in a repo whose default branch can't be determined. ^ had a test for that error; the omitted-target route to the same message had none. The gap predates this branch — the closure is byte-identical to the one it replaces and codecov records those lines as missed at the base commit too — but relocating them into resolve_target_selector re-counted them as patch lines, which is what surfaced it.

Local gate green: 4593 tests, lints, doctests, rustdoc under -Dwarnings.

Behavioral matrix, verified against a build

docs/ (trailing sep)      ▲ Worktree for docs @ ../repo.docs
detached by path          ▲ Worktree for detached worktree @ ../repo.det
leftover dir              ✗ No worktree @ ../repo.leftover
recreated dir             ✗ Worktree directory missing for rec
shortcut ^                ▲ Worktree for main @ ../repo
remove leftover           ✗ No worktree @ ../repo.leftover
--base docs/              ✓ Created branch nf from docs
foreign-repo remove       ✗ Directory @ ../repo.frn is not this repository's worktree
                             precious.txt survives

Also swept, and one thing left alone

Three more instances of the same shape, fixed here:

• resolve_base_ref was the fourth copy of the comparison, so --base docs/ now resolves too.
• hint_for_repo suggested wt switch ^ after an existence probe a recreated directory passes, pointing at a worktree the switch then refuses.
• The pre-switch hook's target var used the bare shortcut expander, so a hook saw docs/ where the switch resolved docs.

The identical unborn/stale default-branch block in require_target_branch and require_target_ref is extracted. The rest of that pair differs in its existence predicate, extra arms, and final error; sharing it would cost more in parameters than the duplication does.

Left alone: live_sibling_checkout decides whether another worktree still holds a branch during removal, and also uses exists(). Switching it to prunable would make branch deletion more likely in a corner case where the detached path already answers the other way. That is a data-safety surface and a separate decision.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

Three findings, inline. The first is the one I'd want settled before merge — the new prunable test isn't a superset of the Path::exists() checks it replaces.

Also a merge-order heads-up rather than a finding: #3770 rewrites the same detached-worktree arm of prepare_worktree_removal this PR inserts the is_prunable() branch into, and adds a remove_branch_with_prunable_detached_worktree snapshot. Whichever lands second will need its arm re-derived rather than textually merged — this PR changes detached + absent directory from "fall through to the removal error" to WorktreeMissing.

Evidence for the locked-worktree finding

git 2.54.0, three linked worktrees, directory removed from each; wt2 locked first:

worktree /tmp/ptest/wt1
branch refs/heads/f1
prunable gitdir file points to non-existent location

worktree /tmp/ptest/wt2
branch refs/heads/f2
locked

worktree /tmp/ptest/wt3
branch refs/heads/f3
prunable gitdir file points to non-existent location

wt2 — absent directory, locked — carries no prunable attribute, so WorktreeInfo::is_prunable() (self.prunable.is_some()) is false for it. That is git's pruning policy (a lock means "don't prune this"), not a health verdict, which is what makes it a narrower test than exists() rather than a wider one.

The repo already treats this state as realistic: the lock guard in prepare_worktree_removal cites #3645 with "a temporarily-absent directory (removable media, a network mount, a dropped VPN) is exactly the case git worktree lock exists for".

[worktrunk-bot]

All three findings from the previous review check out as fixed, verified against the code rather than the commit message:

• worktree_is_unusable leads with !path.exists() and falls through to prunable, so the locked-and-absent case is caught again. All three sites that had lost it — usable_worktree_for_branch (the wt merge / wt step push path), plan_switch, and hint_for_repo — go through it, and worktree_is_unusable_covers_locked_absent_and_recreated pins all four states.
• Selector::branch_only() in resolve_switch_target takes the path arm off where create is in scope, and resolve_selector returns BranchOnly before both path steps — so the worktree-by-path lookup and the directory verdict switch off together, which makes the comment on the NoWorktreeAtPath arm true again. The pr:/mr: early returns already produce rewritten_to, so they're unaffected.
• map_token and resolve_worktree_name are gone; git grep finds no remaining references outside the CHANGELOG's historical entry.

Two docstring inaccuracies inline, both on lines this PR adds.

Not approving — this is the removal surface. The diff changes src/git/remove.rs and src/commands/remove.rs, and widens what wt remove --force refuses to delete. Per the repo's review guidance a change to what wt remove --force can reach isn't an agent's to sign off on, however good the change looks — and the ownership check here is exactly the kind of thing worth a human reading twice, since it's the only thing standing between a stale registration and an unrelated repository. Nothing outstanding from me; it wants a human on the merge.

codecov/patch is red at 95.77% (9 misses on 213 patch lines). That matches the count you handed over in the map_token thread, so I'm not re-deriving it — flagging only because CLAUDE.md makes it a merge gate that needs an explicit call.