A worktree from an earlier session is still on disk and holds two commits you never pushed. You run the cleanup sweep and it leaves the directory alone, so you then remove that worktree by name to tidy up. What happens at each step?

The principle — two operations on the same object behave in opposite ways, and the safe one teaches the wrong lesson about the other.

Why the key is correct — read the two sentences side by side. The sweep skips a worktree that still holds work: changed or untracked files, or unpushed commits. That is why nothing happened at the first step, and it is also why the sweep feels safe — for the ordinary case it is, since each subagent gets a temporary worktree that Claude Code removes automatically when the subagent finishes without changes. Then the explicit removal: removing deletes the worktree directory and its branch, along with all the work in them. The two unpushed commits lived on that branch and nowhere else, so they are gone, and the sweep's caution is precisely what made the second step feel like a formality. A learner who has internalised the first behaviour will get the second one wrong, which is what makes this worth a hard slot rather than a definition.

Why the others are wrong — the first has the sweep taking a worktree that still holds work, which is the one thing it is documented not to do. The second keeps the branch and the commits, which removal takes with the directory. And the last treats a worktree as free to recreate, when a new one is a fresh checkout you have to initialise your development environment in — and the commits are not in the repository to recreate from.

Remember this — the sweep protects work it can see; naming a worktree for removal destroys it. Push, or move the branch, before you tidy.

Sources — Anthropic's Claude Code documentation on running parallel sessions with worktrees.