Copilot code review now reads instructions from the pull request branch

GitHub changed which branch supplies custom instructions to Copilot code review. The reviewer now reads supported instruction files from the pull request’s head branch—the branch proposing the change—instead of the base branch that will receive it. For engineering teams, that changes how review guidance enters each run and who can alter it within a pull request.

That branch change is only one part of the review design. Teams also need to decide how Copilot’s review environment is prepared, whether it runs on GitHub-hosted or self-hosted infrastructure, and what network access that choice permits. Those dependencies lead to an explicit policy for review inputs, runtime setup, runners, and egress.

The pull request branch now supplies Copilot’s review instructions

In its July 17, 2026 changelog, GitHub says Copilot code review now reads custom instructions from the head branch. The supported sources named in the announcement include copilot-instructions.md, path-specific *.instructions.md files, agent skills, and AGENTS.md. GitHub also added support for REVIEW.md, GEMINI.md, and CLAUDE.md.

Teams can now change review guidance on a feature branch and test it before merging that guidance into the base branch. A pull request can also change both the code being reviewed and the instructions Copilot uses to review that code. The instruction change should therefore be visible as part of the proposal rather than treated as fixed repository policy.

This behavior is not, by itself, evidence of an exploit or vulnerability. It is a product choice that makes review instructions branch-provided input. Our interpretation is that repositories using Copilot review should assign ownership to those instruction files, make changes to them conspicuous in review, and avoid treating Copilot comments as independent approval of the instructions that produced them.

GitHub’s CODEOWNERS behavior provides a useful distinction. CODEOWNERS is read from the pull request’s base branch, while Copilot’s supported review instructions now come from the head branch. That lets a team use base-branch ownership rules to request human review when a pull request changes instruction files, provided the patterns and branch rules are configured correctly.

Review-specific setup can be separated from Copilot cloud agent setup

Copilot code review runs in an ephemeral development environment and uses a GitHub Actions workflow file to prepare that environment. According to GitHub’s code review environment documentation, a repository can define review-specific setup in .github/workflows/copilot-code-review.yml. Teams can use it to install dependencies, prepare tools, or select a runner suitable for review work.

If that review-specific file is absent, Copilot code review falls back to .github/workflows/copilot-setup-steps.yml when the repository has one. That fallback matters because the latter file may already prepare the environment for Copilot cloud agent. Adding copilot-code-review.yml gives a team a separate place to define what review needs, without automatically coupling review setup to the cloud agent’s setup.

Separation is useful when review requires a smaller toolset than implementation work. A reviewer may need a compiler, package metadata, and a focused test command, while a coding agent may need broader build or deployment tooling. BaristaLabs recommends keeping review setup limited to what can improve review quality and making ownership of this workflow as explicit as ownership of other automation that executes repository code.

The workflow file is operational input. A change to it can alter installed software, preparation steps, or runner selection. Teams that already apply controls to AI-assisted workflows should include this file in the same change-review and ownership policy as the instruction files.

Runner selection determines whether GitHub’s Copilot firewall is available

GitHub says Copilot code review runs behind a firewall by default on the supported path, with network policy configurable separately from Copilot cloud agent. “Configurable” does not mean the review has zero internet access. It means administrators can set the network policy for code review independently, and the allowed destinations still need to match the dependencies the review environment must reach.

The boundary changes with self-hosted runners. GitHub states that self-hosted runners do not currently support its Copilot firewall and that reviews on those runners continue without that GitHub firewall. This does not establish that a self-hosted runner has unrestricted internet access: outbound access depends on the network controls, proxies, firewall rules, and routing that the operator applies to the runner environment.

GitHub also split organization-level runner settings for Copilot code review and Copilot cloud agent. An organization can therefore choose different runner types for the two workloads instead of inheriting one shared runner choice. The announcement does not establish that every account received every control at the same time, so administrators should verify the settings exposed in their own organization rather than infer plan eligibility from the product description.

The runner decision should follow the review’s real dependencies. GitHub-hosted execution provides GitHub’s supported Copilot firewall path; self-hosting may provide access to private package mirrors, internal build systems, or specialized hardware, but the operator then owns the egress policy that replaces the unsupported GitHub firewall. Neither choice proves full isolation, and runner type alone says nothing about secrets, fork behavior, or effective privileges.

Teams should decide who controls review input, execution, and egress

A workable policy starts by naming the trusted source for each part of the review. Head-branch instruction files shape what Copilot looks for. The review workflow shapes the runtime, runner selection determines which network controls are available, and repository rules determine which human approvals are required before merge.

For instruction files, decide which team owns them and whether changes require that team’s approval. For .github/workflows/copilot-code-review.yml, decide which tools are permitted and whether it may select a self-hosted runner. For egress, record whether the review uses GitHub’s configurable firewall or operator-managed controls, then list only the destinations needed for package retrieval, source access, or internal services.

One bounded test can confirm that these decisions match actual behavior. In a temporary branch, make an obvious, harmless change to a supported review instruction and a reversible review-setup step, then request Copilot review on a small pull request. Confirm that the head-branch instruction affects the review, the expected workflow and runner are used, one approved network destination succeeds, and one deliberately unapproved destination is blocked; remove the temporary changes after recording the result.

That test verifies a narrow path, not every security property of the service. GitHub’s cited material supports claims about instruction source, setup-file precedence, runner configuration, and firewall support. It does not, on its own, prove which secrets are available, how every fork scenario behaves, what privileges a particular runner grants, or that the full review environment is isolated from every other system.

Human merge controls should cover the files that shape AI review

Copilot review should remain one input to merge decisions. GitHub’s CODEOWNERS documentation says repositories can require code-owner approval for changed files and recommends protecting the CODEOWNERS file itself by assigning it an owner. Apply that mechanism to the instruction and review-workflow paths when those files influence a required or widely trusted automated review.

The specific decision is straightforward: choose who may approve head-branch review instructions, whether code review gets a dedicated setup file, which runner class it uses, and who owns the resulting egress rules. Write those choices into repository ownership and branch rules, then exercise the path with the bounded test above. If you want an outside review of one automated code-review path—from instruction ownership through runner egress—BaristaLabs can help you trace and tighten it.

Sources

• GitHub: Copilot code review customization and configurability improvements
• GitHub Docs: Use Copilot code review
• GitHub Docs: About code owners