claude-code - 💡(How to fix) Fix [BUG] "View PR" button sticks to the first PR when a session creates multiple PRs across different branches [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46625Fetched 2026-04-12 13:37:20
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×4commented ×2

Error Message

Error Messages/Logs

(No error output — this is a UI routing bug, not a crash or tool failure. The GitHub MCP tools succeed and return the correct PR URLs; only the "View PR" UI button resolves to the wrong PR.)

Root Cause

Those reports all frame the root cause as "branch-name cache not invalidated." My repro uses different branch names, which rules out branch-name caching as the explanation. The only state shared between the two PRs in my repro is the Claude Code session ID itself, which strongly suggests the UI caches a session_id → pr_number mapping at the first create_pull_request tool use and never re-resolves it.

Fix Action

Fix / Workaround

Workarounds I tried from inside the session that did not work:

  1. Calling mcp__github__update_pull_request on the newer PR to make it the most recent GitHub tool call.
  2. Removing the https://claude.ai/code/session_... link from the merged PR's body so a body-scan would only match the newer PR.

Workarounds attempted (none worked)

  1. Calling mcp__github__update_pull_request on the newer PR to make it the most recent GitHub tool call.
  2. Removing the https://claude.ai/code/session_... link from the merged PR's body.

Code Example

(No error output — this is a UI routing bug, not a crash or tool failure. The GitHub MCP tools succeed and return the correct PR URLs; only the "View PR" UI button resolves to the wrong PR.)
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

What's Wrong?

In a Claude Code session that creates multiple pull requests on different branches, the "View PR" (PRを表示) button stays pinned to the first PR — even after that PR is merged and a newer PR is created later in the same session on a different branch. The button opens a merged PR with a "Merged" badge, and there is no way to reach the newer open PR from the button. Users have to copy the new PR URL out of Claude's chat text manually.

Confirmed on both the Claude Code mobile app and the web UI.

This looks related to but distinct from several previously auto-closed reports:

  • #30757 — stale PR link after branch switch (Closed, Not Planned)
  • #11161 — "View PR" routes to merged PR when reusing the same branch name (Closed, Not Planned)
  • #34042 — duplicate of #30757
  • #15313 — mobile variant, duplicate of #11161

Those reports all frame the root cause as "branch-name cache not invalidated." My repro uses different branch names, which rules out branch-name caching as the explanation. The only state shared between the two PRs in my repro is the Claude Code session ID itself, which strongly suggests the UI caches a session_id → pr_number mapping at the first create_pull_request tool use and never re-resolves it.

TUI already received a parallel fix in #24834 ("only show open PRs", completed Feb 2026). The mobile app and web UI have not.

Workarounds I tried from inside the session that did not work:

  1. Calling mcp__github__update_pull_request on the newer PR to make it the most recent GitHub tool call.
  2. Removing the https://claude.ai/code/session_... link from the merged PR's body so a body-scan would only match the newer PR.

Neither had any effect on the button target, consistent with server-side caching of the session → PR mapping.

What Should Happen?

The "View PR" button should open the most recently created PR associated with the current session, preferring open PRs over merged ones.

Specifically:

  1. Re-resolve the session → PR mapping on every create_pull_request / update_pull_request tool use, not cache at first call.
  2. Prefer the most recently created PR whose head branch matches any branch the session has pushed to (not just the currently checked-out one).
  3. Prefer open PRs over closed/merged ones.
  4. If only merged PRs exist, hide the button or label it explicitly (e.g. "View merged PR #N") so users aren't surprised.

A merged PR is a historical commit, not an actionable PR — linking the "View PR" button to it is strictly misleading.

Error Messages/Logs

(No error output — this is a UI routing bug, not a crash or tool failure. The GitHub MCP tools succeed and return the correct PR URLs; only the "View PR" UI button resolves to the wrong PR.)

Steps to Reproduce

  1. Start a new Claude Code session. Ask it to fix something small. Claude creates a branch (e.g. claude/feature-a), pushes it, and calls mcp__github__create_pull_request. PR #N is created and appears as the target of the "View PR" button. ✅ correct at this point.

  2. Review and merge PR #N on GitHub (outside Claude).

  3. In the same Claude Code session, ask Claude to do an unrelated task. Claude checks out main, creates a different branch (e.g. claude/feature-b), pushes it, and calls mcp__github__create_pull_request again. PR #N+1 is created and is in the "open" state. Claude's chat output contains the correct URL https://github.com/OWNER/REPO/pull/N+1.

  4. Tap/click the "View PR" (PRを表示) button at the bottom of the conversation screen.

Expected: browser opens PR #N+1 (open). Actual: browser opens PR #N (merged). The merged PR page loads with a "Merged" badge. PR #N+1 is unreachable from the button.

Key detail for reproduction: the two branches must have different names (claude/feature-a vs claude/feature-b), to distinguish this from the branch-name cache bug reported in #11161 / #30757. No branch reuse, no branch rename, no git push --force.

Reproduced on both:

  • Claude Code mobile app (iOS)
  • Claude Code web UI (browser)

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

/A — mobile app / web UI bug, not CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Important: this bug is NOT in the Claude Code CLI. It is in the Claude Code Android mobile app and the web UI (claude.ai/code) accessed via Chrome on Android. The CLI-specific fields above (Claude Code Version, Terminal/Shell, Operating System) do not apply — I filled them in only because they are required. The bug_report.yml template does not currently have a good path for reporting non-CLI bugs; you may want to add a separate template for mobile/web.

Reproduced on

  • Claude Code Android mobile app
  • Claude Code web UI via Chrome on Android (claude.ai/code)

Both surfaces show identical behavior. iOS and desktop browsers not tested.

Related auto-closed issues (branch-name cache framing, all closed Not Planned)

  • #30757 — Desktop app shows stale PR link after branch switch
  • #11161 — "View PR" routes to merged PR when reusing branch name
  • #34042 — duplicate of #30757
  • #15313 — mobile variant, duplicate of #11161

This report is distinct

All of the above frame the root cause as "branch-name cache not invalidated." My reproduction uses two different branch names (claude/feature-a and claude/feature-b), which rules out branch-name caching as the explanation. The only shared state between the two PRs is the Claude Code session ID — strongly suggesting a cached session_id → pr_number mapping that is set at the first create_pull_request tool use and never re-resolved.

TUI already has a parallel fix

#24834 ("Footer shows closed/merged PR indicator — should only display open PRs") was completed Feb 2026 for TUI. The Android app and web UI have not received the equivalent treatment.

Workarounds attempted (none worked)

  1. Calling mcp__github__update_pull_request on the newer PR to make it the most recent GitHub tool call.
  2. Removing the https://claude.ai/code/session_... link from the merged PR's body.

Consistent with server-side caching of the session → PR mapping, not a body-scan at click time.

Please do not auto-close as duplicate

All four related reports were auto-closed due to 60-day inactivity, not because they were fixed. Please read the "This report is distinct" note above before closing this as a duplicate of them.

extent analysis

TL;DR

The "View PR" button should be updated to resolve the session → PR mapping on every create_pull_request / update_pull_request tool use, instead of caching it at the first call.

Guidance

  • The issue is likely caused by server-side caching of the session_id → pr_number mapping, which is set at the first create_pull_request tool use and never re-resolved.
  • To fix this, the mapping should be re-resolved on every create_pull_request / update_pull_request tool use, preferring open PRs over merged ones.
  • The "View PR" button should be updated to open the most recently created PR associated with the current session, based on the re-resolved mapping.
  • If only merged PRs exist, the button should be hidden or labeled explicitly to avoid misleading users.

Example

No code snippet is provided as the issue is related to the UI routing and server-side caching, and the exact implementation details are not available.

Notes

The issue is distinct from previously reported issues related to branch-name caching, as it uses different branch names and the only shared state is the Claude Code session ID.

Recommendation

Apply a workaround by updating the "View PR" button to re-resolve the session → PR mapping on every create_pull_request / update_pull_request tool use, and prefer open PRs over merged ones. This should be done until a permanent fix is implemented to update the server-side caching mechanism.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING