[BUG] Desktop: sessions sharing a working tree show each other's PRs in the PR tracker

Sessions that share a git working tree show each other's pull requests in the desktop app's PR tracker panel. There is no visual distinction between a PR the session created and one that belongs to another session, and approve/merge is one click away — so it is easy to act on the wrong PR.

Reproduction

1. Open two Claude Code desktop sessions on the same repository, both using the same clone and same working directory (no per-session worktree).
2. In session A, create PR #1.
3. In session B, working on an unrelated task, create PR #2.
4. Look at the PR tracker in either session.

Actual: both sessions list both #1 and #2.

Expected: each session lists only its own PR. The agent view docs state that the PR label "appears on individual session rows and reflects work specific to that session."

Does not reproduce with per-session worktrees

Tested both configurations. When each session has its own git worktree, each session shows only its own PR. The leak only occurs when the working tree is shared.

I think that difference is diagnostic rather than exculpatory: if the displayed PRs are resolved by working tree (repo + currently checked-out branch) instead of by session, then giving each session its own worktree makes the lookup key incidentally unique, which would look correct without being correct.

Persisted session metadata appears to be correct

Querying local session metadata, two sessions with an identical cwd and no worktree each carried a distinct prNumber (15 and 32 respectively), correctly matching the PR each one actually created. So the session→PR association is stored per session; the cross-exposure seems to happen when the panel is rendered.

This also suggests the current behavior is not an intentional "show everything in this working tree" design — if it were, there would be little reason to persist one prNumber per session.

Why this matters

Sharing a working tree is a disk-layout decision, not a task boundary. Two sessions in one clone are routinely doing unrelated work, and per-session worktrees are not always practical. Right now the panel treats the former as if it implied the latter, and the resulting list is both confusing to read and risky to click.

Even if repo-scoped listing were the intent, the panel would still need to mark which PR belongs to the current session before offering approve/merge on all of them.

Environment

• Claude Code 2.1.221, desktop app
• Linux (Ubuntu 26.04 ARM64)
• Repository with multiple concurrent sessions in a single clone

I do not have the exact last-good version — the behavior was not present in earlier use, but I did not record when it changed. Possibly relevant: the 2.1.218 changelog entry "Sessions now link to pull requests created after the branch was pushed, including via GitHub REST API" is the nearest preceding change to session→PR linking.

Related

• #57546 — earlier set of issues with the same PR tracker panel (staleness, dismissal, main → main), closed as completed. Different symptom, same surface.