[BUG] Session delete blocked by a false "not pushed anywhere" message on narrow-refspec clones

Summary

The agents view will not delete a finished session. It shows this message:

not deleted · worktree has commits that are not pushed anywhere

The branch in that worktree is on the remote, and the remote holds the same commit as the local HEAD. No key and no flag get past the message, so the session stays in the list.

Motivation

The guard runs this command in the worktree:

git rev-list --max-count=1 HEAD --not --remotes

--not --remotes reads local remote-tracking refs only. The command does not contact the remote. A single-branch clone has a narrow fetch refspec:

remote.origin.fetch = +refs/heads/main:refs/remotes/origin/main

Git updates a remote-tracking ref after a push only when the fetch refspec maps that branch. With the refspec above, a push of feature does not make refs/remotes/origin/feature. The guard then treats the commits as unreachable and blocks the delete. The work is safe on the remote, but the message states the opposite.

The delete action in the agents view already sends force. The force flag opens the guard for uncommitted changes only. The guard for unpushed commits has no force path. So the user cannot delete the session from the UI at all. The only way out is git worktree remove --force by hand, which is the one operation that can destroy real work. A false alarm therefore pushes the user toward the most dangerous command.

This reproduction uses plain git and no agent. It runs the same command that the guard runs:

git init -q --bare remote.git
git clone -q remote.git seed
cd seed
git commit -q --allow-empty -m "initial"
git push -q origin HEAD:main
cd ..
git clone -q --single-branch --branch main remote.git narrow
cd narrow
git checkout -q -b feature
git commit -q --allow-empty -m "feature work"
git push -q origin feature

git branch -r                                    # shows origin/main only
git rev-list --max-count=1 HEAD --not --remotes  # prints a SHA, so the guard blocks
git ls-remote --heads origin refs/heads/feature  # the remote holds that same SHA

The last two commands print the same SHA. The branch is pushed, and the guard still reports it as unpushed.

A user hits this whenever a repository is cloned with --single-branch, or with any other narrow fetch refspec. Large repositories make this common, because a full refspec there fetches many branches.

Proposal

Take one or more of these actions.

1. Ask the remote before the guard blocks. When rev-list finds local-only commits, run git ls-remote <remote> <branch> and compare the answer with the local HEAD. Permit the delete when the remote holds the commit. This removes the false alarm at its source.
2. Give force a path through the unpushed guard, in the same way that force passes the guard for uncommitted changes. A second press of the delete key can show the user's intent.
3. Put the branch name, the worktree path, and a repair command in the message. The present message names the problem, but it gives the user no next step.

Item 1 is the fix. Item 3 helps in the cases that remain, where the commits really are local only.

Environment

• Claude Code version: 2.1.220
• Operating system: macOS (Darwin 25.5.0)
• API platform: Anthropic API
• Regression: unknown