Getting Copilot code review on bot or agent PRs

How do I get Copilot code review to review PRs opened by a bot or cloud agent

Enable GitHub Copilot code review, then request copilot-pull-request-reviewer[bot] on the pull request or switch on automatic reviews for the repository. PRs opened by Copilot cloud agent can still be reviewed, but approvals and GitHub Actions follow separate rules from the review itself.

Copilot code review is requested the same way for a human-authored PR and a bot-authored PR. GitHub documents two paths: you can ask for a review from the Reviewers menu, or you can request copilot-pull-request-reviewer[bot] through the GitHub REST API. If you want every PR in a repository reviewed, use automatic reviews in repository settings.

If the pull request was opened by Copilot cloud agent, do not assume the review path changes. GitHub says Copilot code review and Copilot cloud agent are separate features that share some repository settings, and Copilot code review can review pull requests created by the agent. The useful part is that the PR is still a normal PR, so the reviewer request and automatic review settings still apply.

The part people get wrong is expecting the reviewer to appear just because the PR was created by automation. GitHub does not treat bot-created PRs as self-reviewable by default. You still need Copilot code review enabled at the repo, organization, or enterprise level, and you still need a valid review request flow. If nothing shows up, check whether automatic reviews are off and whether the reviewer request was actually made.

For a manual request, open the PR and add Copilot as a reviewer. GitHub’s docs also show the REST API route, which is useful when another bot opens the PR and your workflow wants to request review immediately after creation. That is the cleanest pattern for owned automation, because the request happens on your repository and does not depend on a person clicking the UI.

If you want the review to happen on every new push, enable automatic reviews and the review-new-pushes setting for the repository ruleset. GitHub notes that Copilot will not automatically re-review a PR after new commits unless you configure that behavior. That is the inconvenient bit, because a bot or cloud agent often pushes follow-up commits after the first review.

Copilot cloud agent changes one more thing: workflow runs. GitHub says GitHub Actions workflows do not run automatically when Copilot pushes changes to a pull request. If your review depends on checks or generated artifacts, you may need to approve and run workflows after you inspect the PR. Review and workflow execution are separate decisions.

Copilot also behaves like a normal reviewer once it starts. You can comment on its review, react to it, hide it, resolve conversations, or ask for changes by mentioning @copilot on a Copilot-authored PR. If you want Copilot to use your repository context, add review-focused agent skills, custom instructions, or MCP servers in the repository settings and files that GitHub documents for code review.

A practical setup looks like this. First, turn on Copilot code review for the repository. Second, decide whether you want manual requests or automatic reviews. Third, if a bot or cloud agent opens the PR, have your workflow request copilot-pull-request-reviewer[bot] right away, or rely on automatic reviews. Fourth, if the PR comes from Copilot cloud agent and uses Actions, inspect the branch before approving workflow runs.

One thing that is easy to miss is that a Copilot review comment is not the same as a merge approval. GitHub says the review includes an approval assessment, but that assessment alone does not satisfy required reviews. If your repo requires approvals, make sure you are looking at the actual review state and not only the summary comment.

If the PR still is not getting reviewed, check the obvious failure points in order: Copilot code review is enabled, the reviewer request exists, the repository is not blocking the feature, and the PR is not waiting on separate workflow approval. That sequence usually finds the problem faster than trying to debug the bot that opened the PR.

For teams using owned automation, the simplest model is this: let the bot or cloud agent open the PR, then have your repository automation request Copilot review immediately, and let humans handle merge approval and workflow approval separately. That keeps the flow predictable and avoids assuming the opener identity changes how Copilot behaves.

If you are building on DevConnect, the same rule applies to your own owned automation: automate the review request on repositories you control, and keep human review and workflow approval as separate steps. You can map the PR flow you want to the same repository-owned pattern used elsewhere on the platform, then document it for your team at DevConnect.

What to do when Copilot does not review the PR

Check whether the PR is actually assigned copilot-pull-request-reviewer[bot]. If it is not, request the reviewer again or enable automatic reviews. Then check whether the repository has Copilot code review enabled in the right scope, because organization and enterprise policy can override repository intent.

Check whether the PR is waiting on a workflow approval rather than a review. GitHub Actions do not automatically run on PRs that Copilot pushes to, and that can make it look like the review never happened when the real block is a paused workflow. The symptom is a quiet PR, not a missing reviewer.

Check whether you are expecting re-review after new pushes. GitHub says Copilot does not automatically re-review unless you configure reviews for new pushes. Bot-driven branches usually change again after the first pass, so the second review is the one that gets forgotten.

When to use the REST API instead of the UI

Use the REST API when a bot opens the PR and your automation already knows the PR number. That lets your pipeline request Copilot review immediately after the PR is created, without waiting for someone to visit the repository page. It is the cleanest option for a cloud-agent or release-bot workflow.

Use the UI when a human is already looking at the PR or when you are verifying that Copilot is available before wiring the automation. The UI is slower, but it is useful for confirming that the repository settings are correct before you add more automation on top.

What Copilot review can use from the repository

Copilot code review can use repository-level agent skills and MCP servers when they are relevant. GitHub says it reads custom instructions, agent instructions, and skills from the head branch, not the base branch. That matters when the bot or cloud agent is changing those files in the same PR, because the review reflects the branch being reviewed.

Short version

If a bot or cloud agent opens the PR, request Copilot as a reviewer the same way you would for a human PR, or turn on automatic reviews. If the PR comes from Copilot cloud agent, remember that review, approval, and workflow execution are separate switches.