Cannot remove detached head worktrees

[mjakl]

I have a few weird worktrees, they show up like this in the switch TUI:

+ -                    ⚑              ⋯        ⋯        ⋯  ../../../../tmp/remy-pre-ah95aa     92d4121c  ⋯     ⋯
+ -                    ⚑              ⋯        ⋯        ⋯  ../../../../tmp/remy-nodejs-0bNNXy  d36377b1  ⋯     ⋯
+ -                    ⚑              ⋯        ⋯        ⋯  ../../../../tmp/remy-b1497dc        b1497dcf  ⋯     ⋯

I can also list them using wt list --branches.

When I try to remove them in the switch TUI (pressing Alt+r), the switch TUI exits with this message, but does not remove the worktree:

✗ No branch named (detached)

It took me a while to figure out that git worktree prune is the way out of this misery, but I was hoping I could do something similar with worktrunk, that being said, I think that worktrunk simply exits is a bug. Whether or not to add a prune function to the switch TUI is a product decision (at least hinting at git worktree prune would surely help lost souls like me).

[max-sixty]

that's not good, thanks for the issue @mjakl

---

@worktrunk-bot please could you repro in a test?

I guess the issue is that we don't know how to address a detached worktree, since it's detached. I'm loathe to officially support replacing branches with paths, in case we lose that canonical branch address, but here it might make sense?

Does wt step prune work? Possibly it fails for the same reason?

[worktrunk-bot]

Thanks for reporting this! I was able to reproduce the issue and identified the root cause: the switch picker used branch names as worktree identifiers, but detached HEAD worktrees have no branch — they all resolved to "(detached)", which then failed branch-based lookup.

I've opened #1665 with a fix that uses the worktree's filesystem path as the identifier for detached worktrees and routes removal through path-based logic. A maintainer will review it shortly.

[worktrunk-bot]

Reproduced and fixed in #1665.

Root cause: The picker's alt-r remove handler called handle_remove(branch_name, ...) where branch_name was "(detached)" for detached worktrees — which doesn't exist as a branch.

Fix: Downcast the selected skim item to access the underlying ListItem, check the detached flag, and route through RemoveTarget::Path (path-based removal) instead of RemoveTarget::Branch. Added a regression test that confirms wt remove (detached) fails with "No branch named (detached)".

Re wt step prune: Yes, wt step prune already handles detached worktrees correctly — it uses RemoveTarget::Path for worktrees with no branch. So that's a viable workaround in the meantime.