Inspect a GitHub Pull Request with gh pr view

You will finish with a repeatable way to inspect a pull request from the terminal, select a pull request explicitly when several are in play, and switch between human-readable, JSON, filtered and browser views. The examples use GitHub CLI 2.87.3, installed here on 23 September 2026. Allow about ten minutes if gh is already installed and authenticated.

You need a shell, GitHub CLI, and access to the repository containing the pull request. This guide only reads pull request data or opens its web page. It does not approve, merge, edit or close anything, so no elevated privileges are needed.

1. Check the installed command

Confirm which executable will run and record its version. These are ordinary, read-only commands:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
https://github.com/cli/cli/releases/tag/v2.87.3

Your path and release date can differ. The option names in this guide are those provided by the installed version. Read the local command help if a later package prints a different field list:

$ gh pr view --help
Display the title, body, and other information about a pull request.

2. View a pull request by number

Change to a local checkout of the repository, then provide the pull request number. Replace the placeholders with the repository you intend to inspect:

$ cd /path/to/OWNER-REPO
$ gh pr view 123
Pull request title
opened by contributor. 2 comments. (label)

  Pull request body

View this pull request on GitHub: https://github.com/OWNER/REPO/pull/123

The final URL, title, body and comment count depend on the real pull request. A number is resolved in the current repository, so check the prompt and working directory before copying a number from another project.

When the checkout is not available, select the repository explicitly with --repo or -R:

$ gh pr view 123 --repo OWNER/REPO

The repository form is [HOST/]OWNER/REPO. The host prefix is useful for a GitHub Enterprise installation. A repository argument does not change your current directory or any Git branch.

3. Select by URL, branch or the current branch

gh pr view accepts a pull request number, a pull request URL or a branch name. A full URL is unambiguous when you are reviewing a link someone sent you:

$ gh pr view https://github.com/OWNER/REPO/pull/123

A branch name selects the pull request associated with that branch:

$ gh pr view feature/example

With no argument, the command looks for the pull request belonging to the current branch:

$ git branch --show-current
feature/example
$ gh pr view

4. Include the discussion comments

The normal view shows the main pull request details. Add --comments or -c when the conversation is part of the review:

$ gh pr view 123 --comments --repo OWNER/REPO

Comments can be long and can contain untrusted text copied from an issue or commit. Treat URLs, shell commands and suggested configuration as review material, not as instructions to run. This command only fetches and prints them.

5. Ask for stable JSON fields

Use --json when another command or a script needs selected fields. This also avoids parsing headings and prose from the default display:

$ gh pr view 123 --repo OWNER/REPO \
    --json number,title,state,author,baseRefName,headRefName,url
{"number":123,"title":"Improve example","state":"OPEN","author":{"login":"contributor"},"baseRefName":"main","headRefName":"feature/example","url":"https://github.com/OWNER/REPO/pull/123"}

The exact JSON is compact and the author object can contain more data than shown here. The available field names are listed by gh pr view --help, including body, files, reviews, reviewDecision, statusCheckRollup and updatedAt.

Do not assume that an omitted field is false, empty or unchanged. Request the field you need and handle missing or null data in the consuming script.

6. Filter or format the JSON

Add --jq to extract one value from JSON. This is useful for a quick check without turning the full response into a shell-parsed string:

$ gh pr view 123 --repo OWNER/REPO --json state,reviewDecision \
    --jq '"state=\(.state) review=\(.reviewDecision // "pending")"'
state=OPEN review=pending

Use // for a deliberate fallback when a field is null. Keep the expression in single quotes so the shell does not expand its punctuation. For a repeatable report with several fields, use --template instead:

$ gh pr view 123 --repo OWNER/REPO \
    --json number,title,state --template '{{.number}}: {{.title}} [{{.state}}]{{"\n"}}'
123: Improve example [OPEN]

Both options format the JSON response; they do not request arbitrary fields. Put the field list in --json first.

7. Open the web view deliberately

Use --web or -w when you need the full GitHub page, visual diff or browser-based review controls:

$ gh pr view 123 --repo OWNER/REPO --web
Opening https://github.com/OWNER/REPO/pull/123 in your browser.

This asks the configured browser to open a remote page. Check the repository and number first, especially when the command came from a pasted message. If a browser cannot be opened, use the printed URL or the terminal view instead.

8. Diagnose failures without escalating privileges

A failure usually means the target, authentication, network or repository context needs checking. Start by printing the command help and verifying the target:

$ git remote -v
$ git branch --show-current
$ gh pr view 123 --repo OWNER/REPO

For an authentication problem, use the GitHub CLI authentication commands appropriate to your organisation and account. Do not paste a token into a command line, shell history or article. For a missing pull request, check that the number belongs to the named repository and that your account can see it. A non-zero exit status is useful to automation, so do not hide it with || true unless the failure is intentionally handled.

Nothing in the examples changes repository state. There is therefore no rollback step. If you later add a command that edits, reviews or merges a pull request, treat that as a separate, state-changing operation and confirm the target before running it.