Submit a Careful Pull Request Review with gh pr review

Use gh pr review to comment on, approve or request changes on a GitHub pull request without leaving the shell. The examples use GitHub CLI 2.87.3, installed as package gh. Allow about ten minutes for a review you have already inspected.

• You need: an authenticated GitHub CLI session, permission to review the repository, and the pull request number, URL or branch.
• No dry run. The installed command has no dry-run flag, and a submitted review changes the pull request.

1. Confirm the installed command

Start with a read-only help check. It needs no elevated privileges and does not contact a repository:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh pr review --help
Add a review to a pull request.

The syntax is gh pr review [number | URL | branch] [flags]. The installed manual says that omitting the argument selects the pull request for the current branch. That is convenient, and an easy way to go wrong if your checkout is not on the branch you think it is.

2. Identify the exact pull request

When the review matters, use an explicit pull request number or URL. A number is interpreted in the repository selected by your current checkout or by --repo:

$ gh pr review 123 --repo OWNER/REPOSITORY --comment --body "Please add a regression test for the timeout path."

The inherited -R or --repo option accepts [HOST/]OWNER/REPO, so include a host only when your GitHub CLI setup uses one.

If you rely on the current branch instead, inspect the branch and repository with ordinary Git first, and remember the argument is omitted:

$ git branch --show-current
feature/example
$ git remote -v
origin  [email protected]:OWNER/REPOSITORY.git (fetch)

A branch name can select a pull request, but the manpage does not promise what happens when several pull requests match or none belongs to it. An explicit number or URL removes the ambiguity.

3. Choose exactly one review action

The command offers three mutually distinct actions:

• --comment: submits a review comment without approving or requesting changes.
• --approve: approves the pull request.
• --request-changes: requests changes on the pull request.

Keep the action visible in the command. Do not copy a command from a previous review and change only the body. An approval and a change request mean different things, and the short forms -a, -c and -r are easy to confuse when scanning shell history.

4. Submit a short inline body

Use --body or -b for a short, already-written message. This example submits a comment to pull request 123:

$ gh pr review 123 --repo OWNER/REPOSITORY --comment --body "Please add a regression test for the timeout path."

Shell quoting is part of the safety check. Double quotes preserve spaces, but the shell still expands things inside them. Use single quotes for ordinary text containing a dollar sign, or put a multi-line message in a file. Never interpolate untrusted issue text or a generated command into the body without checking what the shell will expand.

Output and its exact wording vary by GitHub CLI release and server. A returned shell prompt alone is not evidence. Check the pull request in the GitHub interface or your normal review workflow, and confirm the new review has the intended action and body.

5. Submit a multi-line body from a file

For a longer review, write the text in a temporary file and inspect it before submission. This keeps shell quoting out of the review message:

$ cat > /tmp/pr-review.txt
The change is close. Please add a regression test for the timeout path.

Once that test passes, this comment should be ready to resolve.
^D
$ sed -n '1,20p' /tmp/pr-review.txt
The change is close. Please add a regression test for the timeout path.

Once that test passes, this comment should be ready to resolve.
$ gh pr review 123 --repo OWNER/REPOSITORY --comment --body-file /tmp/pr-review.txt

--body-file reads the review body from the named file. The manual also supports - to read from standard input, but a file gives you a visible checkpoint before the state-changing command.

Once you have confirmed the review is present, remove the temporary file if it contains sensitive material:

$ rm -- /tmp/pr-review.txt

That removal is local and irreversible, and it does not remove the submitted review from GitHub.

6. Approve or request changes after the final check

Once the body, repository and pull request number are confirmed, use the matching action. These commands submit state-changing reviews:

$ gh pr review 123 --repo OWNER/REPOSITORY --approve --body "The requested tests pass and the implementation looks ready."
$ gh pr review 123 --repo OWNER/REPOSITORY --request-changes --body "Please handle the timeout error before merging."

Run only one of the two lines. They are alternatives, not a sequence. For a neutral observation, use --comment instead. If you are unsure which action reflects your review, stop and settle that through the repository's normal process.

7. Keep the boundary clear

gh pr review adds a review to an existing pull request. It does not create a pull request, change files, merge code or alter local Git history. Its options are limited to the review action and body, plus the inherited repository selector.

• Approval does not merge. Do not expect --approve to merge anything.
• Review is not a CI result. A successful review is not proof that automated checks passed.
• Scripts need fixed inputs. Pass a fixed pull request identifier and a fixed body file, record the exit status, and verify the remote review.
• No secrets in the body. Keep access tokens and private incident details out. A review is visible to everyone who can access the repository and may be kept in its audit history.