[BUG] Cowork launcher PR-ancestry walker treats default branch as a non-trunk when historical PR exists with default as head

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

The Cowork launcher persistently shows a stale, historical PR as a "parent" above the active PR/session for a project. The stale PR is one where the repo's default branch (main) was the head branch — e.g. an old long-lived integration branch where main → integration-branch PRs were merged. The launcher's PR-ancestry walker treats main as if it has a parent PR above it, even though main is the repo's trunk.

The chip appears in two states:

• When there's no active PR for the current session, it's shown alone as the "default" context.
• When there is an active PR (e.g. main ← my-feature-branch), it's stacked above the active PR row (integration-branch ← main, with a "Merged" badge).

What Should Happen?

Expected

The launcher should treat the repo's default branch as the trunk and stop walking PR ancestry past it. There should be no "parent PR" shown above main.

Actual

The historical PR is rendered above the active PR/session indefinitely, with no UI affordance to dismiss it. Right-clicking the chip does nothing useful; clicking it opens the PR on GitHub but doesn't offer a "hide" option. Project settings don't expose a "trunk branch" override.

Error Messages/Logs

Steps to Reproduce

1. Have a repo whose default branch (main) was once the head of a now-merged PR — i.e. somewhere in GitHub history there exists a PR with head_ref = main and base_ref = some-other-branch. (In our case, an old auth0 migration integration branch from 2024.)
2. Open the project in the Claude desktop app's Cowork launcher.
3. Observe the launcher always renders that historical PR as the parent of main, in the direction other-branch ← main with "Merged" status.

<img width="1149" height="138" alt="Image" src="https://github.com/user-attachments/assets/c2b908e1-b978-406d-bf95-d46a73fb3efb" />

Environment

• macOS (Darwin 25.3.0 / Sequoia)
• Claude desktop app (latest as of 2026-05-08)
• git 2.51.2 (Homebrew)
• Repo uses reftable ref backend

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.133 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workarounds tried (none worked)

• Clearing the desktop app's Local Storage leveldb cache (signs out and rebuilds — chip comes back identically).
• Fixing .git/HEAD to ref: refs/heads/main.
• Removing all linked worktrees and .claude/worktrees/.
• pkill -fi claude, full app quit, relaunch.
• git update-ref -d on stale refs, git worktree prune.

State persists across all of the above, which strongly suggests the offending PR data is reconstructed from GitHub's PR history server-side per project, not from any local cache.

Related bug worth flagging

The launcher reads .git/HEAD as a plain file rather than resolving HEAD via git. In a repo using the reftable ref backend (extensions.refstorage = reftable, default-able in git 2.51+), .git/HEAD is a vestigial loose file that git itself ignores — its contents can be arbitrarily stale. In our case it had been parked at ref: refs/heads/.invalid since March, while git correctly reported HEAD as refs/heads/main the entire time.

This caused the launcher's branch chip to display .invalid for the project for months, with no way to fix it from the UI (clicking, signing out, restarting, removing the project — all no-ops). The fix on our side was a manual printf 'ref: refs/heads/main\n' > .git/HEAD to make the loose file match what git already believed.

The launcher should resolve HEAD via git symbolic-ref HEAD (or equivalent) instead of reading the file directly. Otherwise any reftable repo is a ticking timebomb for this class of UI bug.