GitHub Copilot CLI

Install GitHub Copilot CLI and Sign In

Use GitHub's stable npm package, @github/copilot, with Node.js 22 or later. On Windows, GitHub also requires PowerShell v6 or higher. If your organization supplies Copilot, its administrator must enable the Copilot CLI policy. Installation requirements.

Run this in your terminal:

npm install -g @github/copilot

If your ~/.npmrc sets ignore-scripts=true, GitHub gives this alternative: npm_config_ignore_scripts=false npm install -g @github/copilot. Other documented installers are winget install GitHub.Copilot on Windows, brew install --cask copilot-cli on macOS or Linux, and curl -fsSL https://gh.io/copilot-install | bash on macOS or Linux. The Node prerequisite belongs to the npm route. GitHub's install commands.

Navigate to the repository you want to work on, then enter copilot. Confirm you trust that folder, either for this session or for future sessions. If you are not signed in, enter /login inside Copilot when prompted. First launch.

Choose GitHub.com, or your GitHub Enterprise Cloud data-residency hostname. Choose the browser flow on a local desktop; remote or headless environments normally offer the device-code flow first. Complete the browser authorization, authorize relevant organizations if they use SAML SSO, and approve the GitHub Copilot CLI application. Return to the terminal after sign-in completes. You can also start authentication from your shell with copilot login. Authentication instructions.

If the CLI picks the wrong account, check existing COPILOT_GITHUB_TOKEN, GH_TOKEN and GITHUB_TOKEN variables: explicitly exported tokens override the stored login. For automation, GitHub supports a personal-account fine-grained token with the Copilot Requests account permission. Classic personal access tokens are unsupported. Authentication and token precedence.

Your First Jobs: Explain, Fix, Open a PR

Start with a question, then a change you can verify, then a pull request. Think of the CLI as a developer at your workbench: it can inspect the project and operate tools, while you decide which actions it may take.

The table distinguishes shell commands from input inside an interactive copilot session. Each command or prompt below appears in GitHub's documentation. Every model interaction draws AI credits; GitHub does not publish a fixed credit price for these jobs. CLI billing mechanics.

Explain the Repository Before Changing It

A developer joining an unfamiliar project could start with the explanation command in the table. GitHub's example selects Claude Haiku 4.5; -p sends a single prompt and exits, -s suppresses extra output, and --model selects the model. If that model is unavailable under your plan or policy, use an interactive session and /model to choose what is available. Free and Student accounts use Auto selection. Programmatic example, model access.

Use the explanation to locate the entry points and test setup, then verify those files yourself. The payoff is a concrete starting map you can question, rather than another unstructured tour through directories.

Fix a Failing Test With a Visible Finish Line

A maintainer with a broken test could run the repository's actual test command, give Copilot the failing output, then use the table's interactive prompt. GitHub supplies that wording in its test-driven development workflow, after creating and reviewing failing tests. For an existing failure, provide the same missing context: which test fails and what behavior it should preserve. Review the diff and rerun the relevant test before accepting the change. GitHub's test workflow.

For a test already failing in CI, the automated checks attached to an existing pull request, GitHub gives /pr fix ci focus on test failures. This investigates logs, applies fixes and can push changes, so treat it as a different workflow from a local test repair. It requires an existing PR for the current branch. Fixing CI failures.

Open a Pull Request After Reviewing the Change

A founder shipping a small fix could use /pr create from the working branch after reviewing and committing the change. You must be in a Git repository hosted on GitHub. Copilot pushes local commits and creates the PR, following the repository's PR template for its title and description. If the branch already has a PR, the command updates it. Creating a pull request.

That gives you a reviewable handoff through the team's existing GitHub workflow. It does not remove your responsibility for what the branch contains.

What Copilot Asks Before Running Commands

Folder trust and tool permission are separate decisions. When an action needs approval, you can allow it once, approve the tool for the running session, or decline and give feedback. Session approval covers the tool with its options. Approval prompts.

Read-only operations can run automatically; potentially destructive actions, writes and URL access require approval unless already granted. Some prompts offer saved approval for the repository or directory. Permanently approved URL domains apply across sessions. Saved permissions.

GitHub's example of preconfigured permissions is:

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

This permits Git commands while denying pushes. Deny rules beat allow rules and saved approvals. /reset-allowed-tools clears session approvals and saved tool approvals for the current location, returning to the permissions established at launch. Allow and deny rules.

--allow-all-tools approves every available tool. --allow-all or --yolo also approves all paths and URLs. GitHub recommends using broad approvals in an isolated environment. Keep the ordinary approval flow for your first jobs. Broad permission options.

Which Plans Include It, and What Gets Billed?

All Copilot plans include the CLI: Free, Student, Pro, Pro+, Max, Business and Enterprise. There is no separate CLI subscription to add to your existing Copilot seat. Here are the current monthly prices and allowances on GitHub's plans page. Copilot plans.

Flex is a variable allotment, so the current totals are not a permanent capacity promise. One AI credit equals $0.01 USD. The selected model's prices and the input, output and cached tokens determine the amount used. Chat and CLI draw from the same allowance. Paid-plan code completions and next edit suggestions remain unlimited and do not consume AI credits. Individual billing.

For an existing Pro subscriber, the subscription line stays at $10 monthly; terminal model work competes for the current 1,500-credit allowance. That is the useful business math: try the access you already own, then judge whether the shared allowance fits your work. Paid individuals can budget for additional usage, upgrade, or wait for the monthly reset. The public pricing table does not offer additional-credit purchases on Free. Individual allowances, Free-plan purchasing limits.

Business and Enterprise credits pool at the billing-entity level. Additional paid usage is enabled by default and administrators can disable it. A user budget or enterprise spending limit can stop access even when another allowance remains. GitHub recommends CLI 1.0.48 or later for accurate billing and usage displays. Organization billing.

Check /usage after a job for session credits and model token usage. You can set /limits set max-ai-credits NUMBER in an interactive session, replacing NUMBER with your chosen allowance. The minimum is 30 credits. This feature is in public preview and is a soft limit: an in-flight response finishes and can slightly exceed it. Usage display, session limits.

Which Models Can Copilot CLI Use?

Use /model inside Copilot to see your choices, or --model for a shell invocation. GitHub's current client table marks these models as supported by CLI; your plan and administrator's policies can narrow access. Supported models.

GitHub's separate CLI Auto table also includes GPT-6.1 Sol. Free and Student use Auto only. Availability changes, so use the picker for your account's current options. Auto and plan availability.

Add Project Instructions and MCP Tools

Write the repository's working rules before asking for repeated changes. Custom instructions are Markdown files Copilot includes as context. Put project-wide build commands, test commands and conventions in .github/copilot-instructions.md. Use .github/instructions/**/*.instructions.md with applyTo patterns for rules that concern specific paths. Custom instructions.

The CLI also discovers AGENTS.md, CLAUDE.md, .claude/CLAUDE.md and GEMINI.md. User-wide preferences can live in ~/.copilot/copilot-instructions.md or ~/.copilot/instructions/**/*.instructions.md. Applicable instructions combine; GitHub does not define a general precedence order between them. Keep them consistent, and use /instructions to inspect or disable discovered files. Instruction discovery and interaction.

MCP, Model Context Protocol, connects an agent to external tools and data. Think of it as adding a service connection to the workbench. The GitHub MCP server is already built in. For another server, use /mcp add, move between fields with Tab, and save with Ctrl+S. Local or stdio servers run a process; HTTP servers connect to a remote endpoint. Legacy SSE is also supported. Adding MCP servers.

GitHub's terminal example is copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp. User configuration lives in ~/.copilot/mcp-config.json; project configuration can use .mcp.json or .github/mcp.json. The dedicated MCP guide states that configured organization registry and allowlist policies apply to CLI. Terminal example, configuration and policies.

When to Use the CLI, the IDE, or Another Agent

My recommendation: start with Copilot CLI when the job already lives in your terminal and you have a Copilot seat. Choose the IDE extension when you want to work beside the file you are editing, inspect changes visually and stay in your editor. Our Cursor vs GitHub Copilot comparison helps with that editor decision.

Beyond the first jobs, these are useful possibilities:

• A maintainer preparing a review could ask for a code review of the working branch, investigate the findings, then hand the diff to a human reviewer. The payoff is a focused review checklist, provided the findings survive verification. GitHub documents local review workflows. Review guidance.
• A developer answering PR feedback could use /pr fix feedback, inspect the proposed edits and approve the resulting pushes. The payoff is keeping requested changes and the discussion together. The command can reply to and resolve addressed review threads, so review its scope before approval. Feedback workflow.

Consider another terminal agent when you need a different subscription allowance, provider arrangement or control over the agent itself. Use our Claude Code alternatives and terminal costs comparison for that purchase decision. First check whether Copilot's own model options meet your requirement: GitHub also documents bringing your own provider, including compatible local models. That route has separate provider configuration and requires tool calling and streaming; it is a different setup from using your Copilot allowance. Bring your own model.

What a Small Team Could Build Around It

A repository onboarding pack is the strongest starting opportunity. Developers search for “how to understand a new codebase” and “ai tool to understand codebase.” A team could sell a maintained package of architecture notes, verified build instructions and bounded onboarding tasks to engineering leads. The smallest useful version would cover the customer's repository and demonstrate the explain, test and PR workflow. The catch: generic prompts are easy to copy; maintained project knowledge is what the buyer would pay for.

A review preparation workflow is another possibility. Searches for “ai code review tools” and “ai powered code review platform” point to the job. A team could package project instructions and connected issue context to produce a review packet with changes, test evidence and unresolved questions. The buyer would be a team lead standardizing handoffs. The catch: generated findings need validation, and the workflow must earn its place beside GitHub's existing review features. These are product possibilities, not demonstrated results.

Limits You Should Plan Around

The CLI can produce a plausible change that is wrong. GitHub's responsible-use guidance says generated output can be inaccurate or incomplete and tells users to verify CLI code and commands. Passing the relevant tests and reviewing the diff remain part of the job. Responsible use.

Folder trust is not guaranteed isolation. GitHub describes directory permission scoping as heuristic and does not guarantee protection of every file outside trusted directories. Start in the repository you intend to work on. For tighter restrictions, /sandbox enable enables local sandboxing of tools; GitHub's local and cloud sandboxes are in public preview. Directory trust and sandboxing.

Access and spending limits still apply. A model listed in the documentation may be unavailable to your plan or disabled by policy. CLI usage shares credits with other Copilot work, and the preview session cap can overshoot slightly. Organization budgets can halt usage without an automatic switch to a cheaper model. Model access, session caps, budget behavior.

For your next working session, pick an actual failing test on a branch you can review. Explain the relevant code, approve the repair's tool requests, rerun the test, inspect /usage, then open the PR. That produces a concrete decision about workflow fit and consumption.

If you want a repository workflow built around your team's checks and connected tools, we build AI automation.