Worktree exit dialog counts commits since worktree creation (CLAUDE_BASE), not unmerged work — warns 'will be lost' for fully pushed and merged commits

Summary

The interactive exit dialog of a worktree session (/exit in a session started with claude --worktree) warns:

You have N commits on worktree-\<name\>. The branch will be deleted if you remove the worktree. 1. Keep worktree 2. Remove worktree — All changes and commits will be lost.

N is git rev-list --count CLAUDE_BASE..HEAD, where CLAUDE_BASE (stored in .git/worktrees/<name>/CLAUDE_BASE) records the ref the worktree was created from. The number therefore measures "commits made since the worktree was created" — it says nothing about whether those commits are pushed or merged, and the "All changes and commits will be lost" claim is wrong for the most common worktree finishing flow.

This is related to, but distinct from, the ExitWorktree-tool reports #78355 (canonical), #40137, #71135 and #84856: those are about the tool's ancestry check against the default branch false-positiving after squash merges. The interactive dialog misfires with no squash involved at all, because its baseline is worktree creation rather than the default branch: commit → push → regular (even fast-forward) merge on the remote still leaves N > 0.

Observed in a real session: the dialog showed N = 3 while git rev-list --count origin/main..HEAD was 0 (everything contained in the remote default branch). After git merge --ff-only origin/main inside the worktree, the dialog showed N = 4 — the count grew while the worktree converged on the server state. It only returns to 0 if HEAD is reset back to the creation-time state.

Reproduction

1. In any repo with a remote, start claude --worktree test.
2. Inside the session, make one commit on the worktree branch, push it, and merge it into the default branch on the remote (a regular or fast-forward merge — no squash needed).
3. git fetch, confirm git rev-list --count origin/main..HEAD prints 0.
4. /exit, choose "Remove worktree": the dialog warns "You have 1 commit … All changes and commits will be lost", although removing the worktree loses nothing.
5. Optional: run git merge --ff-only origin/main in the worktree and open the exit dialog again — the count increases.

Expected

Either count work that would actually be lost (unpushed/unmerged commits, e.g. against the remote default branch, plus uncommitted files), or have the dialog state what the number measures ("N commits since this worktree was created") instead of claiming loss.

As #84856 put it for the tool-side check, the hazard is reflex-training: a warning that fires on every routine PR workflow (commit → push → merge on the remote → discard worktree) teaches users to confirm removal reflexively, so the one time the warning is real it reads exactly like the previous false alarms.

Environment

• Claude Code 2.1.251
• Linux
• plain git repository