[BUG] Bottom status row PR badge on long-lived background jobs stays pinned to the first PR ever linked, even after it merges

Open 💬 0 comments Opened Jul 15, 2026 by gorkem2020

Environment

  • Claude Code v2.1.210, Linux, native install
  • Long-lived daemon background job (agents view, "Continue project from previous session" flow), created 2026-07-04 and respawned many times since
  • The badge in question is on the native bottom status row (next to the permission-mode indicator and background task counts), not a custom statusLine script

What happens

The bottom status row shows a PR badge ("PR #911"). On our long-lived background job it has displayed the same PR for 11 days across every respawn, even though that PR merged weeks ago and dozens of newer PRs were created from the same job since.

Mechanism, from inspecting ~/.claude/jobs/<jobId>/state.json:

  • The job keeps an append-only children array. A link scanner walks the job transcript (linkScanPath / linkScanOffset) and registers every GitHub PR URL that appears as {"id", "href", "kind": "pr"}.
  • The status badge appears to render the first entry of that array. Our job's children[0] is exactly the displayed PR, and the badge did not change while 31 newer PR entries accumulated behind it over 11 days.
  • Entries are never re-checked against GitHub, so merged and closed PRs stay registered forever.
  • Registration is by URL appearance in the transcript, so PRs that were merely discussed (not authored or touched by the session) are registered too.

Editing state.json while the job runs does not stick (the daemon rewrites it from memory on every state change); the only workaround we found is stop the job, strip children entries with kind: "pr", then reattach.

Why it matters

For a short-lived job that produces one PR, first equals latest and the badge is genuinely useful. On a long-lived job the badge degenerates into a fossil pointing at an ancient merged PR, which reads as "something is stuck" and sent us debugging.

Suggestion

Any of these would fix it:

  • Render the most recent open PR authored (or touched) by the session, instead of the first registered entry
  • Lazily re-check and drop merged/closed entries from the badge
  • When more than one PR is registered, render a count that expands to the list

Repro sketch

  1. Start a background job; create or mention PR A in conversation: badge shows "PR A"
  2. Merge PR A; create or discuss PRs B through Z over days in the same job
  3. Badge still shows "PR A" indefinitely

Related (same stale-PR-state family, other surfaces)

  • #75717 merged/closed PRs linger as un-dismissable chips (desktop)
  • #71326 desktop session PR picker shows stale merged/closed cards
  • #70389 no session event when a tracked PR merges/closes
  • #67479 closed feature request to disable the status-bar PR badge
  • #75887 docs issue describing the v2.1.205 PR-linking behavior

View original on GitHub ↗