Copilot code review picks up a firewall, custom runners, and head-branch instructions

The first time an AI reviewer left a "did you mean to log the auth header?" note on one of my PRs, I stopped rolling my eyes at the whole idea. It was a comment I would have missed at 6pm on a Friday. That is the DX bar for review-time AI, and it is why the July 17 changelog from GitHub caught my eye. Copilot code review picked up a firewall, custom setup steps, independent runner configurations, and one small behavioural change to how custom instructions are read.

The last item is the one you will feel first.

What actually shipped

Per the GitHub changelog dated July 17, Copilot code review can now run with a firewall around it, with custom setup steps, and with its own runner configuration independent of the rest of your Actions setup. Alongside that, custom instructions, meaning the copilot-instructions.md file and any *.instructions.md files, are now read from the head branch of the pull request instead of the base branch. GitHub frames the whole bundle as giving administrators and developers more control over how the reviewer runs inside their environment.

That is the entire announcement. The head-branch change alone is a workflow-shape change worth pulling apart.

Head-branch instructions, in plain terms

Before this change, if you wanted to update how Copilot reviewed your code, you had to land the instructions on the base branch first. Then open a PR against that base and see whether the new prompt actually did what you hoped. If it did not, iterate on main, then try again. If you have ever tuned a lint config in a shared repo, you know how much that friction adds up.

Reading from the head branch flips it. The instructions that live in the PR are the instructions the reviewer uses on the PR. You can propose a rule change and watch it take effect in the same review it is written into.

For anyone who has spent time trying to convince a review bot to stop flagging your test fixtures, that is a same-PR change instead of a multi-PR ceremony.

The reviewer starts to look like a CI job

The firewall, the custom setup steps, and the independent runner configuration are the other half of the story, and I read them as GitHub admitting the reviewer is a build in disguise. It fetches source. It resolves dependencies. It runs against your code. Every one of those steps is a boundary a platform team needs to be able to draw around.

If your reviewer needs a private registry to install packages before it can reason about them, custom setup steps let that happen. If your compliance team wants the reviewer boxed away from arbitrary egress, a firewall stops being a workaround someone glued together with self-hosted runners. If you want the reviewer running on a different image than your regular Actions jobs, the runner configuration is now its own knob.

None of this is glamorous. All of it is the difference between "the AI reviewer is a hosted feature we tolerate" and "the AI reviewer is a job we control."

Where I would tread carefully

Head-branch instructions are also a supply-chain seam. A PR from an outside contributor can propose an instruction change and get it applied in the same review. If your review workflow has any weight in your merge decision, that is worth thinking about before you turn on the customisations for public repositories. Nothing in the changelog says what the guardrails look like for forked PRs, and I would want that answer before I rolled it wide.

The other thing to test is drift. Instructions on the head branch mean two open PRs can be reviewed under two different rulebooks at the same time. That is fine for experimentation and awkward for enforcement. If your team relies on "everyone gets the same review," you now have to think about which branch of instructions is the canonical one.

What I am watching next

Two things. Whether GitHub publishes concrete guidance for forked-PR handling of head-branch instructions. And whether the runner configuration eventually lets teams point the reviewer at their own compute for cost or data-residency reasons. Both would move Copilot code review from a hosted convenience to a first-class review stage that a platform team can actually own.

If you have already flipped these on for your org, I would love to hear how the head-branch flow lands with your reviewers. Especially the humans.