Worktree branch rename is never seen by the harness, and recovery then drops the session into the main repo

Preflight

Searched existing issues. Two related ones are closed:

• #54653 "[FEATURE] Allow worktree branch renaming mid-session for meaningful git history" — closed as not planned after going stale, and locked. The closing bot asked for a new issue referencing it.
• #53061 "Worktree/branch rename not reflected in session UI; 'View PR' link sticks to original branch" — same gap, different symptom.

This one reports the data loss that follows from the same gap, and asks again for the rename support #54653 wanted.

What happens

Claude Code desktop creates a worktree per session and records the branch it created it on. If that branch is renamed inside the worktree with git branch -m, the recorded name is never updated. When the worktree is later recycled or removed, the recovery path runs git worktree add <path> <recorded branch>, which fails because the ref no longer exists. The session falls back to the main repository:

This session's old worktree was removed and couldn't be re-created, so it now runs in the main repository at /path/to/repo. Your commits on claude/<slug> are safe, but uncommitted files weren't carried over.

Uncommitted work in the worktree is gone. The branch the message names for reassurance does not exist.

Steps to reproduce

1. Start a desktop session in a git repo and let it create a worktree on claude/<slug>.
2. Inside that worktree, run git branch -m my-feature.
3. Leave the session idle long enough for the worktree to be recycled, or remove the worktree directory.
4. Resume the session.

From ~/Library/Logs/Claude/main2.log:

git worktree add --no-checkout .../sweet-herschel-c84baa claude/dev-28493-25a631
fatal: invalid reference: claude/dev-28493-25a631
[CCD] Pool re-lease and fresh-create both failed for session local_b9c668a3… on branch claude/dev-28493-25a631
[CCD] Worktree at .../dev-28493-25a631 was deleted; falling back to origin repo /path/to/repo

The matching rename in the repo's reflog:

Branch: renamed refs/heads/claude/dev-28493-25a631 to refs/heads/dev-28493-fold-messenger-uis-version-file-into-the-vite-build-and

45 of these fallbacks appear across the retained logs on one machine, four of them on the day this was written.

Three problems here

1. The recorded branch is never refreshed, so a rename guarantees recovery will fail later. Nothing warns at rename time, and the failure lands minutes or days afterwards.
2. The failure message gives no cause, and names a branch that no longer exists. Only disk_full and worktree_store_symlinked map to a stated cause; every other git failure prints the bare "couldn't be re-created". The underlying git error is not in the log with the failure either, only a summary warning.
3. The fallback destination is the shared main checkout. Plenty of repos have a working agreement against editing there, so the recovery lands the session in the one place it should not be.

What would help

• A supported way to rename a worktree's branch mid-session that the session and the harness both see, whether that means observing git branch -m or offering a tool or slash command for it. This is what #54653 asked for.
• Recovery keyed on the worktree's identity rather than a cached branch name, or a refresh of that name before it is used.
• The git error surfaced in the notice and logged alongside the failure.
• Somewhere other than the shared main checkout to land, or the option to stop the session and let the user decide.

Why it matters to us

Our repo requires branches named after the ticket they implement. The only way to get from the harness-generated claude/<slug> to that name today is a rename the harness does not observe, so following our own convention costs uncommitted work at unpredictable intervals. We have had to write the rename out of our tooling entirely and work around it by creating a second worktree per session.

Environment

Claude Code desktop 2.1.269, macOS 15 (Darwin 24.5.0).