DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

GitHub Copilot Code Review Setup: Instructions, Firewall, and Runners

#github #githubcopilot #ai #productivity

GitHub Copilot code review setup: instructions, firewall, and runners

Quick answer

GitHub Copilot code review can now read review instructions from a pull request's head branch, use a dedicated .github/workflows/copilot-code-review.yml environment, and run behind firewall and runner settings that are separate from Copilot cloud agent.

For a small repository, start with four layers:

What should the reviewer check?
-> .github/copilot-instructions.md or path-specific *.instructions.md

What rules should every coding agent share?
-> AGENTS.md

What tools and dependencies must exist during review?
-> .github/workflows/copilot-code-review.yml

What network access is actually required?
-> Copilot > Internet access > code review allowlist
Enter fullscreen mode Exit fullscreen mode

Keep GitHub-hosted runners and the default firewall unless a review truly needs private infrastructure. Copilot leaves a Comment, not an approval or request for changes, so deterministic CI and human approval remain the merge gate.

Who this is for

This guide is for solo developers and small teams using Copilot to review pull requests on GitHub. It focuses on the hosted PR review environment, not local /security-review, CodeQL, or code scanning. Use the security review routing guide when the question is which security scanner or autofix stage to use.

If the problem is choosing between AGENTS.md, CLAUDE.md, and tool-specific instruction files across several coding agents, start with the cross-agent instruction file guide. Here, the narrower task is making Copilot's pull-request review reproducible and bounded.

What changed on July 17, 2026

GitHub announced four related changes:

  • Copilot code review now reads copilot-instructions.md, path-specific instruction files, agent skills, and AGENTS.md from the pull request's head branch. It also recognizes REVIEW.md, GEMINI.md, and CLAUDE.md.
  • A dedicated .github/workflows/copilot-code-review.yml can prepare the review environment. If it is absent, code review falls back to copilot-setup-steps.yml when that file exists.
  • A firewall is enabled by default for code review and can be configured independently from the cloud agent.
  • Organizations can choose separate runner types for code review and the cloud agent.

The head-branch change removes an awkward bootstrap problem: a feature branch can introduce and test a new review rule before that rule reaches the default branch. At the time of this guide's source check, some GitHub Docs notes still described base-branch behavior while the dated July 17 changelog explicitly announced head-branch behavior. Treat the dated product change as current, but verify it with a branch-only test rule before relying on it for policy.

Configure the four layers

1. Put each rule in the smallest useful file

Use .github/copilot-instructions.md for repository-wide Copilot review rules. Use .github/instructions/*.instructions.md with applyTo frontmatter for language, directory, or subsystem rules. Keep AGENTS.md for shared facts and commands that should apply across tools.

Do not duplicate the same paragraph in every supported file. Multiple files can be read together, and conflicting rules make review behavior harder to diagnose. A useful instruction is observable: “For payment webhook changes, check idempotency and point to the relevant test,” not “review carefully.”

2. Give code review its own environment only when needed

If the cloud agent and code review need the same tools, keep the existing copilot-setup-steps.yml. Create copilot-code-review.yml when review needs a smaller dependency set, a different runner, or stricter permissions.

A conservative Node.js starting point is:

name: "Copilot Code Review Setup"

on:
  workflow_dispatch:
  pull_request:
    paths:
      - .github/workflows/copilot-code-review.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Checkout code
        uses: actions/checkout@v6
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"
      - name: Install review dependencies
        run: npm ci --ignore-scripts
Enter fullscreen mode Exit fullscreen mode

GitHub's environment documentation requires the job name copilot-setup-steps and recommends least-privilege permissions. --ignore-scripts is a cautious default for repositories that do not need package lifecycle scripts; replace it with npm ci only when the project requires those scripts and the resulting execution is acceptable.

Setup success is not the merge gate. GitHub documents that a failed setup step stops the remaining setup steps, but the review can continue with the environment available at that point. Treat the review session log as evidence of environment quality.

3. Keep the firewall narrow

The recommended allowlist covers common operating-system repositories, package registries, certificate authorities, and browser download hosts. Add a domain or path-scoped URL only when a review rule or tool needs it.

The boundary is important: GitHub says the integrated firewall covers processes the agent starts through its Bash tool, but not MCP servers or processes started in setup steps. It is a useful control, not a complete exfiltration defense. Never place production credentials in review instructions or setup files.

4. Choose runners by risk, not convenience

Use a standard GitHub-hosted runner for ordinary repositories. Use a larger hosted runner only when review context gathering genuinely needs more CPU, memory, or disk. Self-hosted runners may expose internal networks and do not support the integrated code-review firewall, according to the July 17 announcement.

If a self-hosted runner is unavoidable, make it ephemeral and single-use, apply outbound network controls outside GitHub's integrated firewall, grant read-only repository access where possible, and keep production deployment credentials out of the runner.

Validate with one controlled pull request

Use this five-part rollout instead of enabling automatic review everywhere at once:

  1. Add one branch-only instruction for a real subsystem, such as checking duplicate delivery handling in webhook code.
  2. Open a small pull request that changes that subsystem and request Copilot review manually.
  3. Inspect the linked review session: confirm which instruction files, setup steps, tools, and network calls were used.
  4. Record useful findings, false positives, missed rules, Actions minutes, and AI credits.
  5. Merge the rule only after it improves review quality; then consider automatic review for that repository.

Use a compact evidence block in the pull request:

Copilot code review evidence
- Instruction files observed:
- Setup workflow result:
- External hosts required:
- Useful findings / false positives:
- CI checks:
- Human approver:
Enter fullscreen mode Exit fullscreen mode

Common mistakes

  • Writing one large instruction file instead of scoping rules to the changed subsystem.
  • Assuming a new branch rule is active without checking the review session.
  • Letting copilot-code-review.yml inherit write permissions or secrets it does not need.
  • Disabling the firewall because one package host is blocked instead of adding a narrow rule.
  • Using a persistent self-hosted runner that also reaches production systems.
  • Treating a Copilot comment as approval, or replacing tests and human review with AI feedback.

FAQ

Should I create copilot-code-review.yml immediately?

No. Create it only when the default environment cannot inspect the project reliably, or when code review needs a different environment from the cloud agent. Extra setup adds Actions time, network surface, and maintenance.

Does Copilot code review now use instructions from the head or base branch?

GitHub's July 17, 2026 changelog says head branch. Because some documentation text still said base branch when checked, validate with a harmless branch-only rule and the review session log before making it a required control.

Should code review share the cloud agent's firewall and runner?

Only if the requirements are actually the same. GitHub now exposes separate settings, so code review can stay on a smaller hosted runner with narrower network access even when the cloud agent needs a broader build environment.

Can Copilot code review block a pull request?

No. GitHub documents that Copilot leaves a Comment review rather than Approve or Request changes. Use required CI checks and human approvals for merge enforcement.

Sources

Top comments (0)