wt remove <branch> silently strands the worktree when its HEAD is detached

[chachi]

wt remove <branch> on a worktree whose HEAD has since been detached deletes the branch, leaves the worktree, and exits 0 reporting success.

Worktrees go detached routinely — Codex creates one per session, and 0.72.0's own release notes say so. Any of those that started life on a branch is now in this state.

Repro

git init -b main repo && cd repo
git commit --allow-empty -m init
wt switch -c feature
git -C ../repo.feature checkout --detach
cd ../repo
wt remove feature --yes --foreground; echo "exit=$?"
git worktree list

Actual

○ No worktree found for branch feature
✓ Removed branch feature (same commit as main, _)
exit=0
/tmp/…/repo          efb554a [main]
/tmp/…/repo.feature  efb554a (detached HEAD)

The branch is gone, the worktree and its registration are still there, and the
command reported success. Nothing in the output says a removal was skipped: the ○
line reads as information, the ✓ line reads as the result, and a script checking
the exit code sees a clean run.

Expected

Either remove the worktree (it is the one wt switch -c feature created, and
wt remove <path> removes it happily), or refuse — but do not delete the branch and
report success while the worktree stays behind. The failing half is silent, so the
caller learns about it the next time something walks git worktree list.

Notes

• wt remove <path> on the same worktree works on both versions, so this is the
  branch→worktree lookup, not detached removal itself. Cannot remove detached head worktrees #1661 / fix: allow removing detached HEAD worktrees from picker #1665 fixed the picker
  path in 0.71.0-and-earlier; this is a different one.
• Reproduces identically on 0.71.0 and 0.72.0 (x86_64-unknown-linux-musl),
  git 2.50.1, Linux. Repro above runs under a scratch HOME with no user config and no
  repo hooks, so nothing local is involved.

[worktrunk-bot]

Thanks for the report — the repro reproduces exactly as written, and the diagnosis in your notes is right: this is the branch→worktree lookup, not detached removal.

Worktrees are addressed branch-first, and detaching a HEAD severs the only link git records between a worktree and its branch. So resolve_worktree finds nothing checked out under feature, falls through to the branch-only case, and the removal degrades to a plain ref deletion — with no signal that the worktree half was skipped.

#3770 makes it refuse instead of doing half the job:

✗ Branch feature has no worktree — the worktree @ ~/code/myproject.feature is detached
↳ To remove the detached worktree, run wt remove ~/code/myproject.feature

Refusing rather than auto-removing, of the two options you named: once the HEAD is detached only the worktree-path template associates the worktree with the branch, and a commit made on a detached HEAD becomes unreachable when the worktree goes — which is the Codex-session case exactly. So the worktree comes out by path, then the branch, both explicit.

One caveat worth stating up front, since it bounds the fix: the refusal fires when the detached worktree sits at the branch's templated path. A worktree placed outside the template — or one whose worktree-path changed since it was created — still isn't recognized as that branch's, and the branch is deleted on its own. The --help text now says so.

A maintainer will review the PR.

Notes

• Reproduction test: test_remove_branch_with_detached_worktree_refuses in tests/integration_tests/remove.rs — asserts non-zero exit, the branch surviving, and the worktree intact. Confirmed failing before the fix with your exact output.
• The existing test_remove_detached_worktree_in_multi had already recorded the bug: its comment said "feature-b should fail (detached HEAD)" while the committed snapshot showed exit_code: 0.
• The guard sits in wt remove's own target validation rather than in the shared prepare_worktree_removal, because wt step prune plans its whole sweep from one worktree-list snapshot — a detached worktree it is about to remove as its own candidate is still registered when the branch's plan is built, so a refusal there would leave prune unable to clean up either half.
• alt-x on a branch-only picker row keeps the old behavior for now. It's the same mechanism, but the picker shows the detached worktree as its own row, so the branch row is picked over a visible alternative rather than silently. Flagged on the PR for a maintainer's call.