CI monitoring widget shows "gh not installed/authenticated" for all-numeric branch names

Resolved 💬 0 comments Opened Jun 17, 2026 by sean-bryant-mb Closed Jun 18, 2026

Summary

The in-app CI monitoring widget shows "CI checks unavailable — Check that gh is installed and authenticated" for branches whose name is all digits (e.g. a branch named 123456), even when gh is correctly installed and authenticated and CI checks exist and are reporting.

Root cause

The widget appears to resolve the PR's CI status by passing the branch name as a positional argument to gh, e.g. gh pr checks <branch> / gh pr view <branch>. When the branch name is purely numeric, gh interprets the argument as a PR number rather than a branch/head ref, and fails:

$ gh pr checks 123456
GraphQL: Could not resolve to a PullRequest with the number of 123456. (repository.pullRequest)

There is no PR with that number, so the call errors and the widget falls back to the generic "gh not installed/authenticated" message — which is misleading, since the actual cause is argument parsing, not auth.

Verification that gh itself is healthy and the PR is resolvable by head ref:

$ gh auth status
✓ Logged in to github.com account <user> (keyring)  (scopes: repo, workflow, read:org, gist)

$ gh pr checks            # no argument → resolves current branch correctly
<lists all checks, exit 8 because one check is pending>

$ gh pr list --head 123456 --json number,state
[{"number":42,"state":"OPEN"}]   # PR resolves fine when branch is passed as --head, not positionally

Steps to reproduce

  1. Create a branch whose name is entirely numeric (e.g. 123456) and open a PR from it.
  2. Open that branch/PR in Claude Code and look at the CI monitoring widget.
  3. Widget shows "CI checks unavailable — Check that gh is installed and authenticated", despite gh auth status succeeding and checks existing on the PR.

Expected

CI status displays normally regardless of whether the branch name happens to be numeric.

Suggested fix

Resolve the PR from the branch's upstream/remote head ref, not the local branch name, and never pass it as a positional argument to gh. The positional-argument path is what causes the numeric-as-PR-number collision; relying on the upstream ref additionally avoids failures when the local and remote branch names differ (the local branch and the PR's headRefName don't always match). Concretely, either:

  • Determine the remote-tracking branch (e.g. git rev-parse --abbrev-ref --symbolic-full-name @{u}, then strip the remote prefix), resolve the PR via gh pr list --head <remoteBranch> --json number, and operate on the resulting PR number; or
  • Invoke gh pr checks / gh pr view with no positional argument and let gh resolve the current branch's PR via its tracking configuration. gh's own resolution already handles both numeric branch names and local/remote divergence correctly (this is why the no-argument call succeeds where gh pr checks <branch> fails).

Separately, distinguish the "gh failed to run / unauthenticated" error path from the "PR/branch could not be resolved" path, so the message surfaced to the user is accurate rather than the misleading "check that gh is installed and authenticated".

Environment

  • Claude Code on Windows 10
  • gh 2.75.1, on PATH at C:\Program Files\GitHub CLI\gh.exe, authenticated via OS keyring

View original on GitHub ↗