claude-code - 💡(How to fix) Fix Worktree/branch rename not reflected in session UI; 'View PR' link sticks to original branch [1 comments, 2 participants]

Summary

After renaming a Claude Code session's worktree and branch (per the workflow encouraged by global instructions), the session UI continues to display the original auto-generated branch name and links to the PR that was open against it — even after the rename has been fully propagated through git, the GitHub remote, and a re-pinning via EnterWorktree. The only way to recover is to start a new session.

Repro

1. Start a session — the harness creates an auto-named worktree, e.g. branch claude/angry-albattani-431ab2 at .claude/worktrees/angry-albattani-431ab2/.
2. Open a PR from that branch (PR #N).
3. Rename per global instructions:
   • git branch -m claude/<task>
   • Move worktree dir: mv .claude/worktrees/<old> .claude/worktrees/<new>
   • Rename git registry: mv .git/worktrees/<old> .git/worktrees/<new> and update the .git file inside the worktree to point at the new path.
4. Try every "tell the harness" lever in turn:
   • Call the EnterWorktree tool with path: <new>.
   • Push the local branch and set a new upstream.
   • Use the GitHub branch-rename API (POST /repos/{o}/{r}/branches/{b}/rename) to rename the remote branch — which auto-closes PR #N because GitHub treats the source ref as gone.
   • Open a replacement PR #M against the renamed branch.

Expected

• The UI's branch indicator picks up the new local branch name.
• The "View PR" link follows the new upstream/PR association (or removes itself when no PR is bound).
• At minimum: the indicator stops pointing at a now-closed PR whose source branch no longer exists.

Actual

• The UI continues to display the original auto-generated branch name (claude/angry-albattani-431ab2).
• The "View PR" button continues to link to the now-closed original PR.
• None of the signals above propagate to the UI; "View PR" is broken (404-equivalent) for the rest of the session.
• Restarting the session is the only recovery.

Impact

The global instructions explicitly encourage rename:

When a session begins with the current branch matching the harness's auto-generated pattern claude/<adjective>-<word>-<hex>, the worktree was created before the task was known. After the first user message makes the task clear, propose a task-relevant rename before doing any work.

Honoring that instruction leaves the session in an inconsistent UI state for the rest of its lifetime, which is genuinely confusing — the user sees a branch/PR mismatch and reasonably suspects something has gone wrong with their work even when git/GitHub are correct.

It also creates an indirect footgun: agents may attempt the GitHub branch-rename API as a UI-syncing measure (as I did above), not realizing it auto-closes the open PR. A new replacement PR has to be created and cross-linked.

Suggested fixes (any of these would help)

• Watch HEAD (and .git/worktrees/<name>/HEAD) for changes and re-derive the displayed branch, upstream, and PR association on every render.
• Expose a tool like RefreshSessionMeta (or have EnterWorktree(path) already do this) so the agent can manually trigger re-derivation after a rename.
• When the upstream branch is changed, refetch the PR association from gh pr view or the GitHub API.
• Document that rename is currently irreversible mid-session, so agents stop being told to do it. (This is the least good option — the workflow itself is healthy.)

Environment

• Claude Code CLI, Opus 4.7 1M context (the model facing this confusion did its best to drive the rename through; that drive is what made the inconsistency painful).
• macOS, bun 1.3.2, gh CLI.
• Repo with multiple long-lived worktrees, including .claude/worktrees/<name> and .worktrees/<name> style.