[BUG] Desktop session list: open-PR marker leaks onto every session sharing the repo directory

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?

In the desktop app's session list, opening a PR from one session paints the PR indicator on
every other session in the same repository, including sessions that never touched git and
sessions that were last active days before the PR existed.

I checked the underlying session metadata (the same data the sidebar renders) and the marked
sessions have no PR linkage at all:

• Exactly one session in that project carries PR state: prNumber: <N>, prState: "OPEN",

on the feature branch that PR was opened from.

• The other marked sessions have no prNumber field whatsoever. Several were last active

3–5 days before that PR was opened.

• None of those sessions carry a branch field either. Only worktree-backed sessions do

(cwd: …/.claude/worktrees/<name>, branch: claude/<name>).

• The repository's currently checked-out branch is that same feature branch — the PR's head ref.

So the indicator is not derived from each session's own metadata. Per the diagnostic work in
#59647, it is a project-scoped cache that is never invalidated: after checking the repo
back out to main (clean tree, PR branch checked out nowhere in that directory), the badge
still renders, and clears only after a full restart of the desktop app.

What Should Happen?

The indicator should be scoped to the session it belongs to, and rendered from that session's
own recorded prNumber / prState / branch. A session with no PR linkage should show
nothing. When the branch state changes, the indicator should be re-derived without needing an
app restart.

Error Messages/Logs

(no error output — this is a rendering/state bug)

Steps to Reproduce

1. Run several sessions in one repository over a few days, all from the repo root (no

worktrees), so they share a single working directory.

1. From one of those sessions, create a branch and open a PR (gh pr create). Leave that

branch checked out.

1. Open the session sidebar filtered to that project.

→ Every session in the project now shows the PR indicator, not just the one that
opened the PR. Clicking the indicator on an older session opens the newer session's PR
(also reported in #66505).

1. Now git checkout main in that directory. Confirm git branch --show-current → main

and a clean tree; the PR branch is checked out nowhere in that directory.
→ The indicator is still shown.

1. Quit and relaunch the desktop app.

→ Only now does it clear.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

/

Claude Code Version

2.1.234 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

This is the desktop app, not the CLI — the Terminal/Shell field above is not applicable.

• Claude desktop app: 1.34493.1
• Claude Code: 2.1.234
• macOS 26.5.1, Apple silicon

Prior reports, both closed without a fix:

| Issue | Title | How it closed |
|---|---|---|
| #66505 | PR indicators incorrectly appearing on all sessions in same repository | Auto-closed as a duplicate of #59647, then locked |
| #59647 | PR status badge is shown in every session's composer, not only the session that created the PR | Closed not planned by the stale bot after inactivity |

#59647 also carries the most useful diagnosis in its comments: per-session worktrees stop
sessions from sharing a HEAD, but they do not fix this — the badge persists after the
branch is gone from the directory and clears only on app restart, so the defect is cache
invalidation and scoping, not cwd resolution. It also notes the leak spans two surfaces: the
composer PR badge and the session-list indicator.

Why file again rather than comment: both issues are closed, and #66505 is locked with a
notice asking that a new issue be filed referencing it.

Still present on current versions. The earlier reports were at 2.1.133 and 2.1.168; this
reproduces on desktop 1.34493.1 / Claude Code 2.1.234.

Possible interaction with #86838. That issue (PR badges resetting to "open" after an app
update) has a comment saying it was fixed in 1.34493.1 — the exact version I'm on. Worth
checking whether the badge-recovery fix there re-broadened the badge's scope. I have not
verified any link; flagging it only so triage can rule it in or out.

Impact: with many sessions per repository, the indicator marks a dozen sessions as having
open PRs when one does, and its links point at the wrong session's PR — which removes the
signal it exists to provide.