How to review GitHub Copilot coding agent pull requests

The first thing to read in a Copilot pull request is not the diff, it is the session log, followed by the workflow approval prompt sitting above it. GitHub's documentation says Actions workflows do not run automatically when Copilot pushes changes, and that a maintainer with write access has to press "Approve and run workflows" before anything executes. That pause exists because the agent can edit the files that run your CI. It is the only step in the process that is designed to make you look. Meanwhile GitHub reports more than one in five code reviews on the platform now involve an agent, and Copilot code review alone has processed over 60 million reviews, growing tenfold in under a year.

What to call it, and what changed in 2026

GitHub renamed Copilot coding agent to Copilot cloud agent on 1 April 2026, because it stopped being a pull request feature. The same release added phases before the code: you can ask it to research the codebase and answer questions grounded in the repository, ask for a plan before it takes any action, and review the full diff on a branch before deciding whether you want a pull request at all.

That matters to a reviewer for one reason. When a Copilot pull request arrives, somebody may have already read a plan and a diff, or somebody may have assigned an issue and walked away. Those two pull requests look identical from the outside, and they deserve different amounts of your time. The session log tells you which one you have.

What arrives in the pull request

The mechanics are documented and worth knowing precisely.

The agent creates its own branch and pushes commits to a draft pull request as it works, and every step is visible in a commit and in the session logs. It opens at most one pull request per task it is assigned, and since April it can also stop on a branch without opening one. Sessions have a hard ceiling of 59 minutes. It only works on GitHub-hosted repositories, and it can only change the repository named when the task started. Since 3 April 2026 it signs its commits, so they show as Verified. It runs on all paid Copilot plans, and administrators enable it for Business and Enterprise.

Two of those facts do real work in review.

The 59-minute limit is a truncation risk. A task that ran out of time does not fail loudly; it produces a change that stops somewhere. The tell is a plausible new component with no caller, or a migration written and never wired up. Look for it in the shape of the change rather than in the diff, where an unreferenced new file looks the same as a referenced one.

One pull request per task means the pull request boundary is the task boundary, which is a different thing from a reviewable unit. If the issue said "add batch sending and clean up the old worker", both arrive together whether or not they should have.

The workflow approval is a review step

Do not click through it. This is the cheapest security review you will ever run.

GitHub's own guidance on reviewing agent pull requests lists CI gaming and untrusted input in workflows among five red flags in agent pull requests. CI gaming is a skipped test, a lowered coverage threshold, or a job moved to a trigger that rarely fires. Untrusted input is a pull request body or issue title interpolated into a prompt and executed with GITHUB_TOKEN permissions.

So before you approve the run, read every changed file under .github/ in full. It is usually twenty lines, and it is the only part of the change that can make the rest of the pull request lie to you afterwards.

One more thing to check about your own repository: since 13 March 2026, administrators can turn that approval requirement off so workflows run immediately. If someone did, a green pipeline on a Copilot pull request was never gated by a person, and you should not read it as though it was.

Your approval does not count, and that is deliberate

GitHub's documentation is explicit: your approval of a pull request Copilot opened for you does not count toward required approvals, and another reviewer must approve before it can merge. The person who asked for the change cannot be the person who signs it off.

As of 1 September 2026, Copilot code review can be authorised to approve pull requests itself, in public preview across the Pro, Pro+, Max, Business and Enterprise plans. It is off by default and configurable at the enterprise, organisation and repository level, and if new commits land after it approves, its approval is dismissed the same way a human reviewer's is.

Whether you turn that on is a policy question for your team rather than a review technique. It is worth knowing which way your repository is set before you read a green check.

Copilot's review and yours answer different questions

Copilot code review has become genuinely capable. Since 27 August 2026 it gives pull requests from the cloud agent a full agentic review rather than the limited feedback it used to, and the old ceiling of 300 files or 20,000 lines no longer applies. It runs on Actions with GitHub-hosted runners, so it can pull in wider repository context. On billing, GitHub said in April 2026 that from 1 June, code review usage moved to AI Credits and also consumes Actions minutes on private repositories, where before it drew only on the premium request allowance.

All of that makes it a strong defect finder. It reads a diff and tells you what is wrong inside it.

What it does not do is tell you what the change did to the system: which components are new, which were touched, what was retired and what still calls it. GitHub's own red flag list includes code reuse blindness, an agent reimplementing a helper that already exists elsewhere in the repository. A duplicate is not a defect in the diff. It looks like clean new code, and it reads clean to a reader whose window is the diff.

When the author and the reviewer are both agents, nobody in the thread has said what the change does.

Put the shape of the change in the same thread

This is why the two things sit together well. Copilot review and PR Lens end up as comments on the same pull request and answer different halves of the question.

PR Lens draws the pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request, updated in place on every push. Green is new, amber is changed, red is gone and struck through, and the parts of the system nobody touched stay on the page. The comment nests drill-downs: the whole blast radius on top, then the new path, then what was retired. Every comment links to a canvas at full size where you can pan, zoom, and press play for a walkthrough that tours the change one step at a time.

Beside a Copilot pull request the useful part is the strike-through. The agent's own summary will tell you it replaced the per-recipient sender. The diagram tells you whether the old one is actually gone, and whether anything still points at it. PR Lens and Copilot code review goes through the overlap properly, including the cost difference.

The ten minutes, with Copilot in the boxes

The clock is the one from how to review a 400-line pull request in ten minutes. Copilot changes what fills each slot.

To ask for changes, mention @copilot in a review comment or push commits to the branch yourself. As with any agent, a comment on a line gets you a change to that line. If the problem is that a component should not exist, say that and name what it duplicates.

If the pull request came from a different agent, reviewing OpenAI Codex pull requests covers the version where the environment configuration is half the evidence, and reviewing pull requests from autonomous agents covers the ones with no session left to ask. The argument underneath all of them is in the complete guide to reviewing AI-generated pull requests.