Read a Pull Request Diff from the Terminal with gh

You will finish with a repeatable way to inspect the changes in a GitHub pull request from a shell, list only the files it touches, and open the same diff in a browser when the terminal view is not enough. The examples use GitHub CLI 2.87.3, the version installed on this machine.

Allow about ten minutes. You need gh, access to the repository, a network connection, and a pull request number, URL, or branch name. The commands only read pull request data, except that --web launches your browser. No sudo is required.

1. Check the installed command

Confirm the binary and version before relying on option names in a script. This is an ordinary read-only check:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)

The relevant command is gh pr diff. Its installed manual accepts a pull request number, URL, or branch as the optional argument. If you omit that argument, it selects the pull request belonging to the current branch.

Checkpoint: make sure you are in the repository you mean to inspect, or plan to pass --repo explicitly. A successful command against the wrong repository is still the wrong review.

2. Show a pull request patch

Replace 123 with the pull request number in the repository you intend to review:

$ gh pr diff 123

The output is a diff for the selected pull request. It is normally longer than a terminal window, so pipe it to a pager when reviewing interactively:

$ gh pr diff 123 | less

Press q to leave less. The command writes the diff to standard output, so you can redirect it to a temporary review file if needed:

$ gh pr diff 123 > /tmp/pr-123.diff
$ test -s /tmp/pr-123.diff && echo "diff captured"
diff captured

Capturing output does not change the pull request. Treat a diff file as potentially sensitive: it may contain credentials accidentally committed in a patch, private source, or configuration values. Remove it from /tmp after review if it should not remain on the machine:

$ rm -- /tmp/pr-123.diff

That removal is irreversible. Check the exact path before running a destructive command, and do not substitute a broad directory for the file shown here.

3. Select the pull request unambiguously

The optional argument can be a number, a pull request URL, or a branch. A URL is useful when the repository is not obvious from your current directory:

$ gh pr diff https://github.com/OWNER/REPOSITORY/pull/123

For a branch, use the branch name exactly as GitHub knows it:

$ gh pr diff feature/example-change

With no argument, the command uses the pull request associated with the current branch:

$ git branch --show-current
feature/example-change
$ gh pr diff

Do not rely on the no-argument form when the branch has several related pull requests, or when you are working in a detached checkout. Supply the number or full URL and remove the ambiguity.

4. Pin the repository when the directory is confusing

Use -R or --repo with the [HOST/]OWNER/REPO form when the current directory is not the repository you want:

$ gh pr diff 123 --repo OWNER/REPOSITORY
$ gh pr diff 123 -R OWNER/REPOSITORY

For a GitHub Enterprise host, include the host component if that is how your gh installation identifies it:

$ gh pr diff 123 --repo github.example.net/OWNER/REPOSITORY

Checkpoint: compare the owner, repository, and pull request number with the review request before interpreting the patch. The command needs access to the selected repository. If it reports an access or authentication failure, fix that separately; do not respond by changing repository settings or copying credentials into a command line.

5. Reduce the output to filenames

When you first want to establish scope, use --name-only. It prints the names of changed files without the line-by-line patch:

$ gh pr diff 123 --name-only
src/example.go
tests/example_test.go
README.md

The filenames above are illustrative. Your output depends on the pull request. This is a useful checkpoint before reading a large change: a surprising path, generated file, or unexpected documentation change may deserve investigation before you spend time on the code.

6. Control colour and patch presentation

The colour option controls terminal colour and accepts always, never, or auto, which is the installed default:

$ gh pr diff 123 --color never | less
$ gh pr diff 123 --color always
$ gh pr diff 123 --color auto

Use never for logs, captured files, or tools that do not interpret terminal colour sequences. Use auto for normal interactive work. For a command whose consumer explicitly expects a patch representation, add --patch:

$ gh pr diff 123 --patch --color never > /tmp/pr-123.patch

Do not assume that disabling colour changes the content of the diff. It changes presentation, not the selected pull request or its files.

7. Open the diff in a browser when required

Use -w or --web to open the pull request diff in your configured browser:

$ gh pr diff 123 --web
$ gh pr diff 123 --repo OWNER/REPOSITORY --web

This hands the selected pull request to a browser. It does not edit, approve, merge, or close the pull request. Treat the URL as sensitive if the repository is private, and check the host and repository before opening a link copied from elsewhere.

8. Diagnose the usual mistakes

If gh pr diff selects an unexpected change, stop and print the current branch, then repeat with an explicit number and repository:

$ git branch --show-current
$ gh pr diff PULL_REQUEST_NUMBER --repo OWNER/REPOSITORY --name-only

If the command says that a pull request cannot be found, check the number, owner, repository, host, and your access to the repository. If it produces no useful terminal colours, that is usually a presentation setting rather than an empty diff; try the always setting interactively or leave the default at auto.

Do not use --web as a substitute for checking the target. Browser history can make it easy to overlook a wrong owner or repository, especially when several projects use the same branch names.