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 push

When 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 api directly against the PR review-comments endpoint to get line-level detail that gh pr view --comments alone doesn't always surface.
• --jq filtering 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 --comments returns the PR's top-level conversation comments; for comments attached to specific lines of a diff, gh api repos/{owner}/{repo}/pulls/{number}/comments is 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

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=482

Gotchas

• Fetching comments with gh pr view --comments and missing line-level detail. Top-level view doesn't surface which exact line an inline comment refers to. Fix: use gh api repos/{owner}/{repo}/pulls/{number}/comments for line-precise feedback.
• Editing the wrong branch because the PR wasn't checked out first. Making changes without running gh pr checkout first can leave you committing to main or an unrelated branch. Fix: always gh 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

FAQs

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.