Responding to PR Review Comments Automatically
Once reviewers leave comments on a pull request, Claude Code can pull those comments, make the corresponding code changes, and push a follow-up commit to the same branch - without you copying feedback into a prompt by hand.
Summary
This workflow has three parts: fetching the review comments, acting on them, and pushing the result.
The gh CLI handles both the fetch and the push; Claude Code handles reading the comments and writing the fix.
Because the follow-up commit lands on the same branch as the original PR, it shows up directly in the existing PR - no new PR is opened.
This is useful both for a developer working interactively ("go address the comments on PR #482") and as a building block for more automated follow-up workflows.
It works the same whether the comments came from a human reviewer or from an automated review bot running Claude Code headlessly.
Recipe
Quick-reference recipe card - copy-paste ready.
# 1. Check out the PR's branch locally.
gh pr checkout 482
# 2. Pull the review comments (ask Claude Code to read and address them).
gh pr view 482 --comments
# 3. After changes are made, commit and push the fix.
git add -A
git commit -m "Address review feedback on PR #482"
git pushWhen to reach for this:
- A reviewer left specific, actionable comments on a PR and you want them addressed without manually re-typing each one.
- You're picking a PR back up after review and want the branch checked out and the comments loaded in one step.
- You're building toward a fully automated "review and fix" loop and need the manual version working first.
- The comments are line-level and reference specific code, which Claude Code can resolve directly against the file.
Working Example
#!/usr/bin/env bash
set -euo pipefail
PR_NUMBER=482
# 1. Check out the PR branch so edits land on the right branch.
gh pr checkout "$PR_NUMBER"
# 2. Fetch the review comments, including inline (line-level) comments,
# via the GitHub REST API through gh api.
gh api "repos/{owner}/{repo}/pulls/$PR_NUMBER/comments" \
--jq '.[] | "\(.path):\(.line) - \(.body)"'
# 3. At this point, ask Claude Code directly:
# "Read the review comments above and fix each one in the codebase."
# Claude Code edits the referenced files.
# 4. Verify nothing else broke.
# (run your project's test command here, e.g. pytest / npm test / go test ./...)
# 5. Commit and push the follow-up.
git add -A
git commit -m "Address review feedback: validate window bounds, add missing test case"
git push
# 6. Confirm the PR now reflects the update.
gh pr view "$PR_NUMBER" --json commits --jq '.commits[-1].messageHeadline'What this demonstrates:
- Using
gh apidirectly against the PR review-comments endpoint to get line-level detail thatgh pr view --commentsalone doesn't always surface. --jqfiltering the API response into a plain readable list Claude Code can act on directly.- Keeping the fix and verification (tests) as an explicit step before committing, not an afterthought.
- Pushing to the existing branch so the follow-up appears as new commits on the same open PR, not a separate one.
- Confirming the push landed by checking the PR's latest commit message.
Deep Dive
How It Works
gh pr checkout <number>fetches the PR's head branch and switches your local working directory to it, creating a local tracking branch if one doesn't already exist.gh pr view --commentsreturns the PR's top-level conversation comments; for comments attached to specific lines of a diff,gh api repos/{owner}/{repo}/pulls/{number}/commentsis more precise, since it returns each comment's file path and line number.- Once Claude Code has the comment text and the file/line it refers to, it edits the referenced code the same way it would for any other requested change.
git push(without-u, once the branch is already tracked from the checkout) sends the new commits to the PR's existing branch, which GitHub automatically attaches to the open PR - it does not open a second PR.- If the PR is protected by required status checks, those checks re-run automatically against the new commits, same as any other push to the branch.
Comment Sources at a Glance
| Source | Command | Best For |
|---|---|---|
| Top-level PR comments | gh pr view <n> --comments | General discussion, non-line-specific feedback |
| Inline review comments | gh api repos/{owner}/{repo}/pulls/{n}/comments | Line-level feedback tied to specific code |
| Formal review summaries | gh api repos/{owner}/{repo}/pulls/{n}/reviews | "Approved" / "Changes requested" verdicts with a summary body |
Bash Notes
# Resolve after applying a fix: mark inline review threads resolved via the
# GraphQL API is not exposed directly by gh pr commands - most teams leave
# threads to auto-resolve visually once the referenced line changes, or
# resolve manually in the GitHub UI after confirming the fix.
gh api graphql -f query='
query($owner:String!, $repo:String!, $pr:Int!) {
repository(owner:$owner, name:$repo) {
pullRequest(number:$pr) { reviewThreads(first:20) { nodes { id isResolved } } }
}
}' -f owner="{owner}" -f repo="{repo}" -F pr=482Gotchas
- Fetching comments with
gh pr view --commentsand missing line-level detail. Top-level view doesn't surface which exact line an inline comment refers to. Fix: usegh api repos/{owner}/{repo}/pulls/{number}/commentsfor line-precise feedback. - Editing the wrong branch because the PR wasn't checked out first. Making changes without running
gh pr checkoutfirst can leave you committing tomainor an unrelated branch. Fix: alwaysgh pr checkout <number>before making any edits. - Pushing without re-running tests. A fix that satisfies the reviewer's comment in isolation can still break something else. Fix: run the project's test suite before committing the follow-up, not just after.
- Vague commit messages like "fix review comments." These make the PR's commit history hard to skim months later. Fix: name what actually changed, e.g. "Validate rate limit window bounds per review comment."
- Assuming a comment thread auto-resolves once the code changes. GitHub doesn't always mark inline threads resolved automatically just because the referenced line changed. Fix: manually resolve the thread in the GitHub UI, or note in a reply comment that it's addressed.
- Re-requesting review before actually pushing the fix. Pinging reviewers before the commit lands wastes their time re-checking nothing has changed yet. Fix: confirm the push succeeded (
gh pr view --json commits) before requesting another look.
Alternatives
| Alternative | Use When | Don't Use When |
|---|---|---|
| Address comments manually in an editor | The fix is trivial and faster to type directly | The comments are numerous or reference logic Claude Code already wrote and understands |
| Reply to comments without code changes | The reviewer's comment is a question, not a requested change | The comment clearly asks for a specific code fix |
| A CI job that auto-responds to comments on every push | You want this fully automated with no developer in the loop | The fixes need judgment calls a scripted rule can't make reliably |
| Batch all comments into one large follow-up commit | The comments are small and related | The comments span unrelated concerns better tracked as separate commits |
FAQs
Do I need to copy-paste the review comments into my prompt?
No - gh pr view --comments or gh api .../comments pulls them directly, and you can point Claude Code at that output instead of retyping anything.
Does this open a new PR for the fix?
No - pushing to the same branch adds commits to the existing open PR; GitHub does not create a second PR for follow-up commits.
What if a review comment is unclear about what change it wants?
Treat it like any ambiguous request - ask a clarifying question or reply to the comment on GitHub rather than guessing at a fix.
Can this work with formal "Changes Requested" reviews, not just inline comments?
Yes - gh api repos/{owner}/{repo}/pulls/{number}/reviews returns the formal review verdicts and their summary bodies, which can be read the same way as inline comments.
Do required status checks re-run after the follow-up commit?
Yes, pushing new commits to a PR's branch re-triggers whatever checks are configured to run on pull_request or push events for that branch.
Should every review comment get its own commit?
Not necessarily - grouping related fixes into one commit with a clear message is usually easier to review than one commit per comment, unless the comments touch clearly unrelated parts of the code.
How do I know which file and line an inline comment refers to?
The gh api .../comments endpoint's response includes path and line fields for each comment, which is why it's preferred over gh pr view --comments for line-level feedback.
Can I mark a review thread resolved from the command line?
Only via the GraphQL API (gh api graphql), since resolving threads isn't exposed through the simpler gh pr REST-backed subcommands.
What happens if I push a fix but the PR has merge conflicts with the base branch?
The push still succeeds and lands on the PR, but the PR itself will show as unmergeable until the conflicts are resolved separately, usually by merging or rebasing on the latest base branch.
Is this different from running Claude Code as an automated review bot?
Yes - this workflow responds to comments already left by someone else (human or bot); an automated review bot is what generates the comments in the first place.
Can I use this to address comments on someone else's PR?
Yes, as long as you have push access to that PR's branch (typically requires being a collaborator on the same repository or the PR being from a branch, not a fork you don't own).
Related
- Creating a Pull Request from a Claude Code Session with gh - how the PR this workflow responds to gets opened in the first place.
- How Claude Code Fits Into Your GitHub Pull Request Workflow - where this touchpoint sits relative to opening and reviewing.
- Running Claude Code as an Automated Code Review Bot in CI - the automated source of the comments this workflow can respond to.
- GitHub Integration Best Practices - patterns for keeping follow-up commits safe and reviewable.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.