How to use GitHub Copilot CLI: a step-by-step guide

To use GitHub Copilot CLI, install it (npm install -g @github/copilot, Homebrew, WinGet or the install script), run copilot in a project folder, confirm you trust the folder, sign in with /login, and describe the task in plain English. Copilot reads your code, proposes edits and commands, and asks before it runs anything.

That’s the basic loop. This guide covers what you need after the first session: which plan you need, interactive and programmatic use, tool permissions, the slash commands worth knowing, models, MCP servers and custom instructions. Everything here follows GitHub’s official documentation on docs.github.com as of October 2026. If you’re still choosing an agent, Copilot CLI vs Claude Code compares the two side by side; this post is the how-to.

What Copilot CLI is

Copilot CLI is GitHub’s coding agent for the terminal. It works on the folder you start it from: it can read and change files, run shell commands, and talk to GitHub through a built-in GitHub MCP server, so it can look at issues and pull requests too. It runs on Linux, macOS and Windows (PowerShell and WSL).

Step 1: check your plan

As of October 2026, GitHub’s plans page says all Copilot plans include Copilot CLI. Usage is counted in GitHub AI Credits, and how fast you use them depends on the model and the amount of work.

If your Copilot comes from an organization, an admin can disable the CLI, so check that first if it refuses to start. The comparison post goes deeper into credits and pricing.

Step 2: install Copilot CLI

On Windows you need PowerShell 6 or later. If your npm config has ignore-scripts set, install with npm_config_ignore_scripts=false npm install -g @github/copilot. /update inside a session updates the CLI.

Step 3: start it and sign in

cd ~/code/my-project
copilot

The first time you start Copilot in a folder, it asks whether you trust the files in it. You can trust it for this session, trust it and remember the choice, or say no. Trusted directories are where Copilot may read, change and run things, so start it in the project folder, not your home directory.

If you’re not signed in, type /login and follow the browser flow. From a normal shell, copilot login does the same, with --device-code for machines without a browser. For automation, Copilot reads a token from COPILOT_GITHUB_TOKEN, then GH_TOKEN, then GITHUB_TOKEN; a fine-grained personal access token needs the “Copilot Requests” permission. /user shows or switches the signed-in account and /logout signs out.

Step 4: work interactively

Type what you want:

Find where we validate email addresses, add a test for addresses with
a plus sign, and run the test suite.

A few input tricks:

• @path/to/file puts a file into the prompt.
• !command runs a shell command directly, without sending it to the model.
• Shift+Tab cycles modes. In plan mode, Copilot asks clarifying questions and builds a plan before writing any code. /plan does the same from the prompt.
• /autopilot lets Copilot keep working on its own until the task is done, and /ask (or /btw) asks a side question without derailing the task.

For anything that touches more than a couple of files, plan first:

/plan Split the 900-line OrderService into smaller services. Keep the
public API the same and list every file you will touch.

Step 5: approvals and tool permissions

When Copilot wants to run a tool that can change something (a shell command, a file write, a URL fetch), it asks. You can approve once, approve that tool for the rest of the session, or say no and tell it what to do instead.

To decide in advance, use permission patterns of the form Kind(argument):

# git is fine, pushing is not
copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

# allow everything except deleting files and pushing
copilot --allow-all-tools --deny-tool='shell(rm)' --deny-tool='shell(git push)'

Deny rules always win, even over --allow-all. Inside a session, /permissions switches between permission modes (default, assisted, allow-all) and /permissions show displays the current mode; /sandbox enable turns on the sandbox. --allow-all (alias --yolo) removes every prompt, so keep it for throwaway containers. AI coding agent security explains why.

Step 6: programmatic use with -p

For scripts and CI, -p runs one prompt and exits. -s prints only the answer, and since nobody is there to approve, you allow tools up front:

copilot -p 'Write a commit message in plain text for the staged changes' \
  -s --allow-tool='shell(git:*)'

copilot -p 'Write unit tests for src/utils/validators.ts' \
  --allow-tool='write, shell(npm:*), shell(npx:*)'

You can also pipe a prompt in: echo "Explain this file: ./complex.ts" | copilot. Useful extras: --no-ask-user stops Copilot from asking questions, --output-format=json emits JSON lines, and --share=PATH saves the session as Markdown. At the end of a run Copilot prints a copilot --resume=SESSION-ID hint so you can continue interactively.

In GitHub Actions, put a token with the Copilot Requests permission in COPILOT_GITHUB_TOKEN:

- name: Coverage summary
  env:
    COPILOT_GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
  run: copilot -p "Run the test suite and produce a coverage summary" -s --allow-tool='shell(npm:*), write' --no-ask-user

Step 7: slash commands worth knowing

From the shell, copilot --resume (or --continue for the latest session) picks up where you left off, and -n NAME names a session so you can resume it by name.

Step 8: choose a model

/model opens the model picker; --model=NAME or the COPILOT_MODEL environment variable sets it at launch, and auto lets Copilot choose. --effort (or --reasoning-effort) sets low, medium, high, xhigh or max for models that support it. Different models use AI Credits at different rates, and long contexts and higher reasoning cost more, so /usage is worth checking now and then.

You can also bring your own model provider. Set COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_TYPE (openai, azure or anthropic), COPILOT_PROVIDER_API_KEY and COPILOT_MODEL. That works with Ollama for local models, as long as the model supports tool calling and streaming; GitHub recommends a context window of 128k tokens or more. copilot help providers lists the details.

Step 9: add MCP servers

The GitHub MCP server is already set up. To add others, use the CLI or /mcp add in a session:

# a local server started with a command
copilot mcp add my-server -- npx -y @example/mcp-server

# a remote server over HTTP
copilot mcp add --transport http my-remote https://mcp.example.com/mcp

Servers are stored in ~/.copilot/mcp-config.json, and a .mcp.json in the repository adds servers for that project:

{
  "mcpServers": {
    "my-internal-server": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "tools": ["*"]
    }
  }
}

tools decides which of the server’s tools Copilot may call; ["*"] means all. copilot mcp list shows what’s configured, and --additional-mcp-config adds servers for a single session. New to MCP? Start with what an MCP server is.

Step 10: custom instructions

Copilot CLI merges instructions from several places:

• AGENTS.md, CLAUDE.md and GEMINI.md in the repository root and the current folder
• .github/copilot-instructions.md
• .github/instructions/**/*.instructions.md, which can be limited to certain paths with applyTo: frontmatter
• ~/.copilot/copilot-instructions.md for personal rules across all projects

/init (or copilot init) writes a starting .github/copilot-instructions.md based on your repo. Keep it short: build and test commands, conventions, and things the agent must not do. If you already keep an AGENTS.md for other agents, Copilot will use it as is. CLAUDE.md and AGENTS.md has tips for writing rules agents actually follow. To start a session without any of these files, pass --no-custom-instructions.

Common pitfalls

• Starting in your home folder. Trust only the project directory; Copilot’s file access follows trusted directories.
• Allowing too much in CI. --allow-all in a pipeline with secrets is asking for trouble. Allow just the tools the job needs and deny git push unless the job pushes.
• Forgetting the token permission. A personal access token without “Copilot Requests” won’t authenticate, and organization-owned tokens aren’t supported.
• One endless session. Long conversations cost more credits. Use /compact or /clear between unrelated tasks.
• Expecting MCP tools without tools. A server entry needs a tools list; use ["*"] to expose everything.

Running Copilot CLI in AgentVera

AgentVera is a desktop app for macOS, Windows and Linux that runs CLI agents side by side in real terminals, using your own installs and logins. Copilot CLI is one of its supported agents; the Copilot CLI in AgentVera page has the details:

• Your GitHub login. Copilot uses its own sign-in. If it’s signed out, run /login in the agent’s terminal; an existing Copilot subscription is enough.
• Model and effort per agent. The model is passed with --model and effort, from minimal to max, with --reasoning-effort.
• Sessions that come back. Each agent gets its own session ID, and a saved session reopens with --resume after a relaunch. /compact works as usual.
• MCP without editing config. Servers from AgentVera’s MCP manager and its browser are added with --additional-mcp-config on every launch, so your mcp-config.json stays untouched. The agent’s role is added as an extra instructions folder.
• Panes, worktrees and review. Run Copilot in the workspace grid next to Claude Code or Aider, give each agent its own worktree from the Git panel, and get automatic code review at the end of each turn. Copilot agents also work in flows (Pro and Team), broadcasts and scheduled tasks.

The grid, worktrees, code review and the MCP manager are on the free plan. Download AgentVera to try it.

Wrapping up

Install Copilot CLI, run copilot in your project, trust the folder and sign in with /login. Plan bigger changes with Shift+Tab or /plan, allow only the tools you’re comfortable with, and use copilot -p with explicit --allow-tool rules for scripts and CI. Put your rules in AGENTS.md or .github/copilot-instructions.md and add MCP servers when you need them. If you also want a git-first agent that works with any model, read how to use Aider.