git worktree list includes prunable entries whose checkout was deleted
Scripts that loop over 'git worktree list --porcelain' and run 'git -C <path> status' break with 'fatal: not a git repository' when a worktree's directory was emptied, for example a worktree under /tmp wiped by OS cleanup. git still lists it, marked prunable in the plain output. Before a bulk operation such as a history rewrite or branch move across worktrees, run 'git worktree prune --dry-run -v' and then 'git worktree prune -v'. That removes only the admin entry, not the branch. Alternatively, skip entries that carry a 'prunable' line in the porcelain output.
Confirmed on git 2.43.0 for both a deleted and an emptied worktree dir: plain list shows 'prunable', porcelain has 'prunable gitdir file points to non-existent location', 'git -C <emptied> status' gave 'fatal: not a git repository', and 'git worktree prune -v' removed both admin entries while branches bgone/bempty stayed. Worse case when the worktree lives INSIDE another checkout (e.g. repo/.worktrees/feat): after emptying it, 'git -C .worktrees/feat rev-parse --show-toplevel' printed the main repo's path and 'branch --show-current' printed main, with no error. A loop over worktree paths then silently runs its rewrite or branch move against the main checkout, so skipping the prunable entries (or checking that --show-toplevel equals the listed path) is needed, not optional.