How to enable GitHub Copilot code review safely: where it runs, what it sees, and which rules it follows

GitHub Copilot code review can automatically review a pull request and point out bugs, weak tests, or risky changes. For a real work repository, though, the first question is not just “are the comments useful?” The first question is: where does the review run, which code can it see, and which rules does it follow?

On June 12, 2026, GitHub added three controls that make this rollout easier to govern: organization-level runner settings, content exclusion support, and no character limit for repository custom instructions. In other words, this is no longer just a button that says “turn on AI review.” It is a set of boundaries you should define before a wide rollout.

Who this is for

This article is for the person who has to answer an uncomfortable question: “Can we enable Copilot code review in this repository now, or is it too early?”

For a learning project, you can start simply. For a monorepo, private product, financial module, security-sensitive codebase, or repository with self-hosted runners, do not enable everything at once.

What changed

GitHub describes three control points.

First, organization runner controls. Copilot code review runs through GitHub Actions, so the runner matters. Organization admins can now set the runner type centrally and, when needed, lock the setting so repository-level configuration does not override it.

Second, content exclusions. Copilot code review now respects repository, organization, and enterprise content exclusion settings. That means specific files or directories can be removed from the context Copilot uses during review.

Third, repository custom instructions. GitHub previously mentioned a 4000-character limit for instruction files under .github. That limit has been removed, so teams can describe local review rules in more detail. That does not mean the instruction file should become a policy novel. Good instructions are short, specific, and maintainable.

A safer rollout order

Do not start with instructions. It is tempting to write “check security, tests, and architecture” and call the process safe. Instructions do not replace access boundaries.

Use this order instead.

First, decide where the review runs. If your team uses self-hosted runners or separate runner pools, verify that Copilot code review cannot drift into an environment that was not meant for it. In an organization, this should be a central decision, not a hidden setting in one repository.

Next, decide what Copilot should not see. That may include secret-bearing configs, internal policy files, generated artifacts, large snapshots, vendor code, or areas of the repository that do not help review. The goal is not to hide everything. The goal is to remove sensitive and irrelevant context.

Only then write repository instructions: which tests matter, which repeated mistakes to look for, which architecture boundaries should not be crossed, and which comments are not useful. Instructions should guide review quality, not compensate for poorly defined access.

A small first run

The first rollout should not cover the whole organization. Pick one repository or one pull request type where the risk is easy to understand: documentation changes, a small backend module, or a service without secret access.

Before the run, write down three expectations:

• review runs only on the approved runner;
• excluded files are not used as context;
• Copilot comments follow your repository instructions.

After that, look beyond comment quality. Check whether the review became noisy, whether exclusions removed important signals, and whether people have to ignore half of the comments.

When not to enable it yet

Postpone the rollout if the team cannot answer three questions:

• who controls the runners used by Copilot code review;
• which parts of the repository should not become review context;
• which review rules the team is willing to maintain in repository instructions.

If the answers are vague, Copilot review will become another source of noise. Worse, the team may get used to automated comments without noticing that the process sees more code than it should or runs somewhere unexpected.

Short version

The new Copilot code review settings are useful not because they make review magically smarter. They are useful because they give teams three practical boundaries: where the review runs, which context it can see, and which rules it should follow.

For a safe rollout, use this order: runners first, content exclusions second, repository instructions third, then a small test rollout. If that feels like bureaucracy, that is the point: automated review is not only about code quality anymore. It also touches access rules around the code.