GitHub Copilot Setup and Enterprise Rollout

A GitHub Copilot rollout has two jobs. The editor or terminal must work for the developer, and the organization must know what Copilot can read, which agents and models are allowed, and who pays for the usage. A seat assignment without repository rules or policy review solves only the sign-in step.

Start with one developer and one Copilot surface, then expand only after an enterprise pilot produces reviewable evidence. Volatile details were checked against GitHub documentation on July 28, 2026.

Copilot is not in my daily rotation, so my evaluation depends on measured pilot results and controls I can verify. The GitHub Copilot guide covers the wider product.

Choose the First Copilot Surface

Pick the surface where the first trial task already happens. A developer who writes in VS Code should begin with the editor extension. Someone working over SSH may learn more from Copilot CLI. A team that wants issue-to-pull-request work should pilot the cloud agent in a low-risk repository.

Work Starts In	Copilot Surface	First Trial
Editor	IDE extension	Explain one file
Terminal	Copilot CLI	Read-only project map
GitHub issue	Cloud agent	Small tested fix
Pull request	Code review	Review known defect

Keep the first pilot to one surface. Each one has different context, policy, and review behavior. One clear task gives you evidence about the product; four simultaneous trials give you results that are hard to compare.

Install and Confirm Access

For an editor trial, install the official Copilot extension or plugin in the developer's existing client. Sign in with the GitHub account that received the Copilot seat. Confirm the account and organization before diagnosing a missing feature, since personal and work identities can have different plan access.

Begin in a non-sensitive repository with a task the developer understands. Ask Copilot to explain a known module, name the test command from the repository, or draft a test plan without editing. Check its file references. A plausible answer that points at the wrong code is a failed setup test.

Then allow one reversible edit. Give the expected file list and validation command in the prompt. Review Copilot's plan, full diff, terminal commands, and test output. Record which model and surface ran the job, because the same prompt can behave differently across clients.

Write Repository Instructions

Repository-wide instructions live at .github/copilot-instructions.md. GitHub says these instructions are added to Copilot requests made in that repository. The file should state facts Copilot otherwise has to rediscover: the build command, test command, project layout, coding rules, and known unsafe actions.

Write rules that a reviewer can check. "Use pnpm and never npm" is testable. "Write clean code" is not. Name the exact command and the area it applies to, but do not turn the file into a copy of every design discussion the team has had.

Commit the file with the repository so changes receive normal review. Add a rule after a repeated, expensive mistake or a settled team decision. Remove a rule when the codebase no longer follows it. Stale instructions can be worse than no instructions because they make wrong output look compliant.

Add Path-Specific Agent Rules

One file may not fit a repository with different languages or risk zones. Path-specific instructions use files named NAME.instructions.md under .github/instructions/. Their frontmatter uses applyTo with one or more glob patterns.

A rule for app/models/**/*.rb can name the model test command without cluttering frontend work. A deployment rule can require review for files under infra/. GitHub currently limits path-specific instructions on GitHub.com to the cloud agent and code review, so verify client coverage before depending on them elsewhere.

Copilot also reads AGENTS.md for coding agents. You can place more than one in the tree, and the nearest file takes precedence. A root AGENTS.md can hold shared rules while a file near the payment code sets stricter checks for that area.

• Repository-wide: .github/copilot-instructions.md
• Path-specific: .github/instructions/NAME.instructions.md
• Agent-specific by location: one or more AGENTS.md files
• Personal: keep personal preferences out of team policy files

Configure Content Exclusions

Content exclusions let repository administrators, organization owners, and enterprise owners tell Copilot to ignore named files or paths. GitHub documents this for Business and Enterprise. Excluded files do not feed inline suggestions, supported Chat responses, or Copilot code review.

The boundary has gaps. As checked on July 28, 2026, GitHub says content exclusions do not support GitHub Copilot CLI, Copilot cloud agent, or Agent mode in Copilot Chat in IDEs. They do not apply to symbolic links or repositories on remote file systems. An editor may also pass semantic details, such as a type definition, from an excluded file.

Use exclusions to control context. Remove credentials from the repository, apply normal access control, and use a secret manager. Test an exclusion from each surface you plan to enable, then document the remaining gaps in the rollout decision.

Set Up Copilot CLI

Copilot CLI is GitHub's current terminal agent and replaces the older gh copilot suggest extension. On macOS or Linux, GitHub documents brew install --cask copilot-cli. On Windows, it documents winget install GitHub.Copilot. Start it by changing into a project and running copilot.

1. Install the CLI with the operating system method your team allows.
2. Open the repository directory in a terminal.
3. Run copilot, then use /login on the first session.
4. Confirm the trust prompt for that directory only after checking the path.
5. Ask for a project summary before allowing an edit or command.

Copilot CLI can read, modify, and execute files below the trusted directory. It can ask for access to another directory when the task needs it. Do not start it from a broad folder that contains several unrelated repositories, credentials, or personal documents.

Enterprise controls differ from editor policy. GitHub says administrators can control CLI access, cloud delegation, custom agents, and MCP policy. It also says path-based content exclusions and IDE-specific policies do not apply to Copilot CLI. Treat the CLI as its own rollout surface.

Plan an Enterprise Pilot

A pilot should answer a purchase question. Pick a small set of repositories that reflect the languages, test quality, and risk the team handles. Include one ordinary service, one weakly documented project, and one repository where access should remain narrow.

Write the review gate before assigning seats. Name who checks agent pull requests, which tests must pass, what requires security review, and which actions are prohibited. A Copilot-generated pull request enters the same branch protection and human review path as any other contribution.

• Track tasks attempted and tasks completed with an accepted diff.
• Record failed checks, reverted changes, and review findings that held up.
• Measure AI-credit use by surface and model.
• Log policy exceptions and content-exclusion gaps.
• Ask developers which work became easier and which work became harder to review.

Avoid a generic acceptance rate. A large number can hide trivial completions or a low review bar. Keep task type, repository, model, time spent, and final review result together so the pilot can explain where Copilot earned a seat.

Set Model Policy and Budget

Organization owners manage features under Copilot policies and models under the model settings. An enterprise owner can enforce a choice above the organization, so an organization may be unable to enable a model that the enterprise disabled. Check both levels when the model picker differs across teams.

GitHub listed Copilot Business at $19 per granted user each month with 1,900 AI credits, and Copilot Enterprise at $39 with 3,900 credits, when checked on July 28, 2026. Enterprise requires GitHub Enterprise Cloud. GitHub also documented a higher promotional credit allowance for existing customers from June through August 2026.

Plan	Price	Listed Credits
Business	$19/user/month	1,900 per user
Enterprise	$39/user/month	3,900 per user

Use the current billing page before approval because prices, credit grants, and promotions can move. Decide who owns the budget, whether extra usage is allowed, and what alert triggers a review. New model access should pass the same policy and cost check rather than appearing by default because it is new.

FAQ

Which Copilot instruction file should I create first?

Start with `.github/copilot-instructions.md` for repository-wide build, test, and coding rules. Add `NAME.instructions.md` files under `.github/instructions/` only when a path needs different rules. Use `AGENTS.md` for coding-agent guidance that should follow the nearest file in the directory tree.

Do content exclusions cover Agent mode?

No. As checked on July 28, 2026, GitHub says content exclusions do not support GitHub Copilot CLI, Copilot cloud agent, or Agent mode in Copilot Chat in IDEs. Treat exclusion as one control, then verify every enabled surface separately.

Can enterprise admins control Copilot CLI?

Yes. An enterprise or organization can enable or disable Copilot CLI, control cloud-agent delegation, apply MCP policies, expose approved custom agents, and record policy changes in audit logs. GitHub also states that IDE-specific policies and path-based content exclusions do not apply to Copilot CLI.

How much do Copilot Business and Enterprise cost?

GitHub listed Business at $19 per granted user each month and Enterprise at $39 per granted user each month when checked on July 28, 2026. Enterprise requires GitHub Enterprise Cloud. Both plans include AI credits, and GitHub was running a June-to-August 2026 promotional credit period.

What to Approve After the Pilot

GitHub Copilot is easiest to govern when the rollout follows the work: one surface, one repository, inspectable instructions, a tested exclusion policy, and a written review gate. That is enough to learn whether the tool helps before an organization pays for broad access.

Business fits a GitHub team that needs central seat and policy control. Enterprise adds the Enterprise Cloud layer, more included credits, and earlier access to some features. Choose after the pilot shows a need for those controls, then verify the live plan and billing pages before assigning the seats.