How GitHub Copilot code review handles agent edits

How does GitHub Copilot code review work with agent edits

GitHub Copilot code review first reviews the pull request itself, then it can turn review comments into agent-driven fixes. The review and the edit are separate steps, and you still stay in control of the final merge. GitHub documents this flow on GitHub Docs, not as a background sync that silently rewrites your branch.

The first pass is the code review. You request Copilot as a reviewer on the pull request, or you configure automatic review so it runs when a PR opens, when a draft becomes open, or on new pushes if that setting is enabled. Copilot then leaves review comments and suggested fixes, usually in under 30 seconds according to GitHub’s docs.

The part people often get wrong is assuming Copilot review and Copilot editing are the same feature. They are not. Review is an analysis step that comments on the diff. Editing happens only after you take one of the suggested actions, such as applying a suggestion or clicking Fix with Copilot on a Copilot review comment.

When you use Fix with Copilot, GitHub says the comment becomes a draft prompt for Copilot cloud agent. You tell the agent what to address, and then you choose whether it creates a new pull request against the branch or commits directly to the same pull request branch. That means the agent edits are explicit, not automatic, and they are scoped to the request you make.

Copilot code review has agentic capabilities that make those fixes more context aware. GitHub says it can gather full project context and pass suggestions to Copilot cloud agent. In plain terms, the review step can reason beyond one file, and the follow-up edit step can use that context to produce a patch that matches the review comment more closely.

Repository context matters. GitHub says Copilot reads repository custom instructions, agent instructions, and agent skills from the head branch, not the base branch, when it reviews a pull request. If you change review instructions in the branch you are testing, Copilot sees those changes in that same PR. That is useful, but it also means a branch can change how it is reviewed before it is merged.

MCP servers can also feed the review. GitHub says Copilot code review can use repository-level MCP servers and agent skills when they are relevant, and the GitHub MCP server and Playwright MCP server are enabled by default. Repository settings apply to both Copilot cloud agent and code review, so one configuration choice can affect both the analysis and the edit path.

The inconvenient part is that Copilot’s review comments do not automatically make the code safe to merge. GitHub tells you to review Copilot output the same way you would review a contributor’s pull request. If Copilot pushes new commits after you ask it to fix something, you still need to inspect the result, because the agent is implementing your request, not certifying the change.

Re-review is not always automatic. GitHub says Copilot will not necessarily re-review after every new push unless you configured automatic reviews to include new pushes. If you make changes after the first review and want a fresh pass, you can request it manually from the Reviewers menu. That is the step people miss when they assume one review covers the whole branch.

A practical example looks like this. You open a PR, request Copilot review, and it flags a missing null check plus a naming issue. You click Fix with Copilot on the null-check comment, describe the exact behavior you want, and let Copilot cloud agent write the patch. Then you open the resulting commit or PR and verify the logic, because the agent may fix the symptom without matching the whole intent of the code.

If Copilot leaves a suggestion that you can apply directly, that is different from asking the agent to edit. GitHub describes suggested changes as ready to apply in a few clicks, which is the simplest path. Agent edits are the heavier path, where Copilot cloud agent generates the code change after your prompt. The review comment can lead to either one.

The safest mental model is: review first, edit second, verify third. Copilot code review identifies issues in the pull request, suggested changes are applied when you choose them, and agent edits happen only when you explicitly hand the comment to Copilot cloud agent. That separation is what keeps the workflow useful instead of surprising. If you want a quick place to start, the official flow is documented on GitHub Docs.

For teams, the hard part is process, not capability. If you enable automatic review on every push, Copilot can keep commenting as the branch changes. If you do not, you need a habit for re-requesting review after agent edits land. The inconvenient truth is that the agent can help write the fix, but ownership of correctness still stays with the human reviewer.

FAQ

Does Copilot code review edit code by itself

No. Copilot code review comments on the pull request first. It only edits code after you apply a suggestion or send a review comment to Copilot cloud agent through Fix with Copilot.

Does Copilot re-review every new commit automatically

Only if you configured automatic reviews to review new pushes. GitHub says otherwise, Copilot reviews once and you need to request another review manually after later changes.

What branch does Copilot read for instructions and skills

GitHub says it reads the head branch, the branch with your changes, not the base branch. That lets you test instruction changes inside the same pull request.

Can Copilot use repository tools during code review

Yes. GitHub says Copilot code review can use MCP servers and agent skills when they are relevant, and some servers are enabled by default.

Should you merge immediately after an agent fix

No. GitHub’s guidance is to review Copilot output thoroughly before merging, because the agent is generating a change, not signing off on it.