Description

gh pr view <N> --json number returns {"number": N} with exit 0 even when N is an Issue number (not a PR). This makes it unreliable for scripts that use it to distinguish PRs from Issues.

Steps to Reproduce

# Replace 1099 with any Issue number in your repo (not a PR)
gh pr view 1099 --json number; echo "exit: $?"
# Output:
# {"number":1099}
# exit: 0   ← wrong: this is an Issue, not a PR

# Adding any PR-specific field correctly fails
gh pr view 1099 --json number,headRefName; echo "exit: $?"
# Output:
# exit: 1   ← correct

Expected Behavior

gh pr view <N> --json number should return a non-zero exit code when N is not a PR.

Actual Behavior

Returns {"number": N} and exit 0 without hitting the API, regardless of whether N corresponds to a PR.

Root Cause

In pkg/cmd/pr/shared/finder.go, the numberFieldOnly optimization skips the API call entirely when only the number field is requested:

numberFieldOnly := fields.Len() == 1 && fields.Contains("number")

if f.prNumber > 0 {
    if numberFieldOnly {
        // avoid hitting the API if we already have all the information
        return &api.PullRequest{Number: f.prNumber}, f.baseRefRepo, nil
    }
    pr, err = findByNumber(httpClient, f.baseRefRepo, f.prNumber, fields.ToSlice())

The issue is that f.prNumber is set simply by parsing the selector string as an integer — it does not confirm the number corresponds to an existing PR. The optimization conflates "we know the number" with "we know it's a PR with that number."

Impact

Any script using gh pr view <N> --json number to detect whether N is a PR will produce false positives for Issue numbers.

Workaround

Add any PR-specific field to the --json flag:

gh pr view <N> --json number,headRefName 2>/dev/null

This forces an actual API call, which correctly fails for Issue numbers.

Environment

• gh version: 2.86.0 (2026-01-21)
• OS: Linux (WSL2)