View multiple PRs created from the same branch #9102

gh pr view with no number picks one PR for the current branch. After gh pr checkout, git often still has branch.<name>.merge set to refs/pull/<n>/head, so view keeps opening that old PR.

Check:

git config --get branch.$(git branch --show-current).merge

If you see refs/pull/123/head, open by number or clear the pin:

gh pr view 456 --web
# or
git config --unset branch.$(git branch --show-current).merge
gh pr view --web

To open the newest open PR for this branch by head name:

gh pr list --head "$(git branch --show-current)" --state open --limit 1 \
  --json number --jq '.[0].number' | xargs -I{} gh pr view {} --web

When lookup is by branch (no refs/pull/N/head pin), the finder loads PRs for that head, prefers OPEN, and orders by CREATED_AT DESC, so a new open PR should beat a merged one.

Checked pkg/cmd/pr/shared/finder.go (findForRefs and the refs/pull/N/head branch-config path) and that gh pr checkout writes branch.*.merge.

gh pr view without a number resolves the most recently updated open PR for the current branch — not necessarily the newest PR number on that branch.

After you merge PR #1 and open PR #2 from the same branch, gh pr view --web may still open the closed PR if it was updated more recently, or if no open PR is detected for your checked-out branch.

Fix: always pass the PR number or URL

# List open PRs for current branch
gh pr list --head "$(git branch --show-current)" --state open

# View the newest open PR explicitly
gh pr view 123 --web

Or in one shot:

gh pr view "$(gh pr list --head "$(git branch --show-current)" --state open --json number --jq '.[0].number')" --web

Recommended workflow after merging

If you reuse a branch name after merge:

git checkout main
git pull
git checkout -b feature/my-change-v2   # fresh branch avoids confusion
# ... commits ...
gh pr create
gh pr view --web   # now points at the new open PR

Why this happens

gh pr view matches by branch + state, and when multiple PRs share history on the same branch name across time, the CLI defaults can feel sticky. Being explicit with --head, --state open, or the PR number avoids ambiguity.

Hope that helps — the explicit gh pr list + gh pr view <num> pattern is what I use on long-lived automation branches too.