Feature Request: API/CLI support for re-requesting PR reviews (including Copilot)

[AndyKorol]

Is your feature request related to a problem?

Yes. When using automated workflows (GitHub Actions, AI coding agents like Codex, Copilot Coding Agent) that iterate on pull requests, there's currently no API or CLI way to re-request a review from a reviewer who has already submitted a review.

Current behavior:

• gh pr edit <PR#> --add-reviewer copilot or the REST API POST /pulls/{pull_number}/requested_reviewers works for the initial review request
• Once Copilot (or any reviewer) has already submitted a review, using the same API call doesn't trigger a new review
• The only way to re-request is through the GitHub web UI by clicking the "re-request review" sync icon (🔄)

Impact:
This breaks AI-agent-assisted development workflows where:

1. AI agent pushes code changes to a PR
2. Bot reviewers (Codex, Copilot Code Review) need to re-review the new changes
3. Without API support, the agent cannot programmatically trigger re-review
4. Manual intervention is required for every iteration cycle

Describe the solution you'd like

Add API/CLI support for re-requesting reviews, matching the existing web UI functionality:

REST API option:

POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers/re-request
{
  "reviewers": ["copilot"],
  "team_reviewers": []
}

Or extend the existing endpoint with a force parameter:

POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers
{
  "reviewers": ["copilot"],
  "force": true  // Re-request even if already reviewed
}

GraphQL:
Add a reRequestReviews mutation alongside the existing requestReviews mutation.

gh CLI:

gh pr edit <PR#> --re-request-reviewer copilot
# or
gh pr review <PR#> --re-request copilot

Describe alternatives you've considered

Workaround	Why it doesn't work
Manually clicking "re-request review" in GitHub UI	Breaks automation - defeats the purpose of CI/CD
Remove and re-add reviewer via API	Doesn't work for bot reviewers like Copilot
Close and reopen PR	Loses context, comments, approval status, creates noise
Use webhooks to detect new pushes	Still can't programmatically trigger the re-request

Additional context

Related discussions:

• No way to re-request a review on a PR created from a fork when the user is an external contributor #151024 - No way to re-request a review on a PR created from a fork
• Configuring automatic code review by Copilot #160286 - Configuring automatic code review by Copilot

Why this matters now:

As AI-assisted development tools become mainstream (GitHub Copilot Coding Agent, OpenAI Codex, Claude, Cursor, etc.), the typical workflow is:

┌─────────────────────────────────────────────────────────┐
│  AI Agent Development Loop (currently broken)          │
├─────────────────────────────────────────────────────────┤
│  1. Agent creates PR                                    │
│  2. Bot reviewers (Copilot, Codex) provide feedback     │
│  3. Agent addresses feedback, pushes new commits        │
│  4. ❌ NO API WAY to re-trigger bot reviews             │
│  5. Human must manually click re-request in UI          │
│  6. Repeat steps 3-5 until clean                        │
└─────────────────────────────────────────────────────────┘

With API support for re-requesting reviews, this becomes fully automatable - a critical capability for the future of AI-assisted software development.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[rushi]

This seems to work for me now: gh pr edit 1234 --add-reviewer "@copilot"

It only works with own PAT. I can't seem todo it using our org's custom app or github-actions bot

Edit: Wanted to mention this works to re-requesting reviews too

[abhi-kj]

I have tried all combinations of the copilot username from "@copilot","Copilot","copilot","@Copilot","github-copilot", none of them are working for the below api using PAT

curl -L -X POST -H "Accept: application/vnd.github+json" -H "Authorization: Bearer xxxxx" -H "X-GitHub-Api-Version: 2026-03-10" https://api.github.com/repos/my.repo.name/pulls/123/requested_reviewers -d '{"reviewers":["@copilot"]}'

the curl get command also does not return the copilot user details even if copilot is added as reviewer,
Note: via the web app, from network tab if i see the get call for suggestion I see the below json for the copilot,
"suggestions": [
{
"id": 175728472,
"type": "user",
"class": "avatar avatar-user",
"selected": false,
"disabled": false,
"ccr_quota_limited": null,
"avatar": "https://avatars.githubusercontent.com/in/946600?s=40&v=4",
"login": "Copilot",
"name": null,
"description": "Your AI Pair Programmer"
}
],
here login says "Copilot" but it does not work for the curl post API.

[urielman]

This worked for me! I had to update the gh cli.

[byronc-synthrics]

Using gh cli works for us inside our GH actions.
You need to use a personal PAT token. The token that we use has the following scopes:

• Contents ( Read)
• Metadata (Read)
• Pull Requests (Read and Write)

      - name: Request Copilot review
        env:
          GH_TOKEN: ${{ secrets.COPILOT_PAT }}
        run: |
          gh pr edit "${{ github.event.pull_request.number }}" \
          --repo "${{ github.repository }}" \
          --add-reviewer "@copilot"

[oleksiilogvin]

It works for me with "copilot-pull-request-reviewer[bot]"

{
    "reviewers": [
        "copilot-pull-request-reviewer[bot]"
    ]
}

[pacnpal]

✅ Workaround: GraphQL requestReviews with botIds

Good news — this already works via the GraphQL API using the botIds field on the requestReviews mutation. This field isn't exposed through the REST API or gh pr edit, which is why it's been overlooked.

How to re-request a Copilot review programmatically

Step 1: Get the PR node ID:

query {
  repository(owner: "OWNER", name: "REPO") {
    pullRequest(number: 130) {
      id
    }
  }
}

Step 2: Request review using Copilot's bot ID:

mutation {
  requestReviews(input: {
    pullRequestId: "PR_NODE_ID",
    botIds: ["BOT_kgDOCnlnWA"]
  }) {
    pullRequest {
      id
      reviewRequests(first: 10) {
        nodes {
          requestedReviewer {
            ... on Bot { login }
          }
        }
      }
    }
  }
}

Using gh CLI:

gh api graphql -f query='mutation { requestReviews(input: { pullRequestId: "PR_NODE_ID", botIds: ["BOT_kgDOCnlnWA"] }) { pullRequest { id } } }'

Bot IDs for common review bots

Bot	Node ID
copilot-pull-request-reviewer	BOT_kgDOCnlnWA
github-code-quality	BOT_kgDODVhblQ
gemini-code-assist	BOT_kgDOCow4Ng
coderabbitai	BOT_kgDOCCSy2w

You can discover a bot's node ID by querying the reviews field on a PR where the bot has already reviewed — the author fragment ... on Bot { id } will return it.

Why this works

The GraphQL RequestReviewsInput type has a botIds field that the REST API and CLI don't surface. This successfully re-requests reviews even after the bot has already submitted one.

Tested and confirmed working as of April 2026. Hope this helps unblock automated workflows! 🚀

[rafal-ep]

I can see this invocation having some effect, as it removes the human PR reviewers from the PR, but it does not appear to trigger a Copilot code review... Copilot is still in a "left comments" state and I cannot request re-review from the Web UI either.

[Ryan-Guo123]

This thread is close to the exact workflow risk I am trying to validate: automated agent PR loops where a bot review is re-requested after new commits. Disclosure: I maintain Relay for Codex: https://github.com/Ryan-Guo123/relay-codex. I am not asking for stars or trying to replace Copilot/CodeRabbit reviews. The question is smaller: before re-requesting a bot review, do maintainers want a pre-review artifact that says what changed, what was verified, what is still missing, and whether the PR should be reviewed, split, or sent back? If the GraphQL/bot-review loop already covers that job, that is useful negative signal. The validation artifact is here: https://github.com/Ryan-Guo123/relay-codex/blob/main/docs/round1-reviewer-request.md. Copy-paste external trial workflow: https://github.com/Ryan-Guo123/relay-codex/blob/main/docs/external-repo-trial.md. Useful outcomes are reused / edited_heavily / ignored / confusing, plus before_review / in_addition / not_needed versus existing AI review tools.

[displague]

Relevant issues: cli/cli#12489 cli/cli#2053

[sugose]

We've been running an AI-assisted development workflow on a Python project where GitHub Copilot Business automatically reviews every PR. Our setup uses the native repository ruleset ("Automatically request Copilot code review") with "Review new pushes" enabled — not a custom GitHub Actions workflow. The ruleset correctly triggers the initial review on PR open, but re-reviews on subsequent code pushes are unreliable despite the flag being set.
After exhausting every known API approach to force re-reviews — REST requested_reviewers, GraphQL requestReviews, dismiss + re-request — all either 422 or silent no-ops — we stumbled onto a pattern that has worked consistently twice:
The pattern:

Push 1: code push (PR open) → Copilot reviews ✅
Push 2: docs-only push (no source code files changed) → Copilot does not review ✅ (expected)
Push 3: code push → Copilot reviews ✅ (this is the surprising one)

Without the docs-only push in between, Push 3 does not trigger a re-review. With it, it does. We've observed this twice, same sequence, same result. It feels deterministic rather than lucky — straight code→code never fires, docs→code always has.
Our hypothesis:

Copilot maintains an internal baseline of "last reviewed commit." When a new push arrives, it compares the diff from that baseline. If it determines nothing meaningful has changed since its last review, it deduplicates and skips. A docs-only push shifts the baseline commit without triggering a review. When the subsequent code push lands, Copilot sees a fresh diff from the new baseline — unreviewed code — and fires.
This would explain why straight code→code doesn't work (Copilot sees the same logical diff it already reviewed) but docs→code does (baseline shifted, new diff is genuinely new to Copilot).
What we don't know:

Whether the pattern holds beyond Push 3 — we haven't tested further iterations
Whether the content of the docs push matters or just the fact of a commit
Whether this is intentional behaviour or a side effect of how Copilot tracks review state

Where we are now:

We'd love to continue investigating but have hit an unfortunate wall: our Copilot credits are exhausted, pausing the investigation at two data points.
We're posting now rather than waiting because we don't know when credits will renew, and we'd rather get this into the conversation while it's fresh. If anyone else can replicate the pattern — a docs-only push between two code pushes on a PR where "Review new pushes" is enabled — that would either confirm or challenge what we're seeing. Two consistent observations from one team isn't conclusive, but it's more signal than random noise.
We'll update the thread when we can resume.