GitHub Copilot CLI: The Complete Guide to the Agentic Terminal Agent

If you last looked at Copilot in the terminal when it was a GitHub CLI extension, reset that mental model. GitHub Copilot CLI is now the standalone copilot command: an agentic terminal coding agent that can inspect a repo, edit files, run tools, delegate work, review diffs, and help you drive a development session without leaving the shell.

That distinction matters. For senior developers, the interesting question is not "can this autocomplete a command?" It is "how much of my local engineering loop can I safely move into an agentic terminal workflow?" The answer depends on your repo, permissions model, tests, automation comfort, and configuration discipline.

Heads up: GitHub Copilot CLI moves fast. It went GA in February 2026 and ships updates constantly, so commands, flags, and available models change often. Everything here was verified against the CLI as of July 2026 -- always check the official GitHub Copilot CLI docs for the very latest.

What GitHub Copilot CLI Is Now: Old vs New

The first thing to get straight is naming. The old GitHub CLI extension used gh copilot and focused on explaining or suggesting shell commands. GitHub now documents that extension as retired. So when I say GitHub Copilot CLI, I mean the new standalone agentic copilot CLI, not gh copilot suggest or gh copilot explain.

The new Copilot CLI is closer to a terminal-native coding agent than a command helper. It can answer questions, edit code, run tests, inspect GitHub issues and pull requests, use MCP tools, and iterate across a session. GitHub's GA changelog describes the shift from terminal assistant to full agentic development environment, and that framing is right for senior developers.

For .NET developers, I think about this as a local engineering loop wrapped in an AI agent. You still own the architecture, tests, and review. But the Copilot CLI can take on a lot of repetitive motion between those decision points.

That also means it is different from the GitHub Copilot SDK for .NET. The SDK is for building Copilot-powered experiences into your applications. GitHub Copilot CLI is the productized terminal agent you use directly.

Install GitHub Copilot CLI and Start Your First Session

As of July 2026, the official install paths are npm, WinGet, Homebrew, an install script for macOS and Linux, or direct binaries from GitHub releases. The npm package is @github/copilot, and the installed command is copilot. The npm path requires Node.js 22 or later. Windows users also need PowerShell v6 or higher.

# Cross-platform npm install. Requires Node.js 22+.
npm install -g @github/copilot

# Windows package manager install.
winget install GitHub.Copilot

# macOS and Linux Homebrew install.
brew install --cask copilot-cli

If you want the prerelease channel, GitHub documents prerelease variants for npm, WinGet, and Homebrew. Keep prerelease installs away from critical automation unless you are explicitly testing new behavior.

Your first session is intentionally simple: run copilot from the repository you want to work in, then use /login or copilot login if authentication is needed. GitHub documents copilot login as OAuth-based, with a browser flow by default, and stores the token in the system credential store when available. For headless use, it can read COPILOT_GITHUB_TOKEN, GH_TOKEN, or GITHUB_TOKEN, in that precedence order. Start GitHub Copilot CLI inside the repository you intend to work on, not casually from your home directory. Trusted-directory scope and file access are part of the safety model.

GitHub Copilot CLI Modes: Standard, Plan, and Autopilot

The Copilot CLI has three interactive modes in the current command reference: Standard, Plan, and Autopilot. You cycle between them with Shift+Tab. This is more than a UI detail because each mode changes how much initiative the agent takes.

Standard mode is the normal conversational loop. You ask, Copilot responds, and it requests approval before running tools that need permission. I use this mode for quick investigation, small edits, and review-oriented prompts where I want tight steering.

Plan mode is where GitHub Copilot CLI becomes more useful for non-trivial work. In Plan mode, Copilot analyzes the task, asks clarifying questions, and builds an implementation plan before touching code. For intermediate-to-senior developers, this is often the right default for changes that cross multiple files. You get a chance to catch the wrong abstraction, missing test scope, or risky migration before the edits begin.

Autopilot mode is the opposite end of the control spectrum. GitHub's GA changelog describes Autopilot as a mode where Copilot works autonomously, executing tools, running commands, and iterating without stopping for approval. That can be powerful. It can also be risky. I would reserve Autopilot for repos with strong tests, clear instructions, and a task boundary that you can review afterward.

The tradeoff is straightforward: Standard gives you control, Plan gives you alignment, and Autopilot gives you throughput. I would not treat throughput as automatically better.

The Agentic Workflow Mental Model: Plan, Build, Run, Review

A better way to use GitHub Copilot CLI is not to throw a vague task at it and hope. The stronger mental model is plan, build, run, review. That mirrors how I want a human engineer to work too.

Start by asking the agent to inspect the repo and propose a plan. Then let it make the targeted change. Then require it to run the smallest meaningful validation command. Finally, review the diff yourself. The CLI gives you /diff for reviewing session changes and /review for analyzing staged or unstaged changes, but those do not replace your judgment.

For a non-interactive version, ask copilot -p "Inspect this repo and propose a plan to add nullable annotations to the public API. Do not edit files yet." -s. For larger tasks, /fleet can delegate parts of a task to parallel subagents, and prefixing a prompt with & can delegate work to the Copilot coding agent in the cloud. I would treat cloud delegation, scheduled prompts, and parallel workflows as advanced or experimental where the docs mark them that way, especially when they can affect branches, pull requests, or external systems.

This is where agentic tooling connects to broader AI engineering patterns. If you are designing your own agent workflows in C#, concepts from Microsoft Agent Framework in C# help explain why decomposition, tool boundaries, and validation gates matter.

The Permission and Approval Model in GitHub Copilot CLI

The permission model is one of the most important parts of GitHub Copilot CLI. The agent can run commands and modify files, so approval is not cosmetic. It is the line between suggestion and execution.

GitHub documents trusted directories, allowed tools, denied tools, allowed paths, URL access, and sandboxing. When Copilot wants to use a tool that can modify or execute files, the interactive experience can ask whether to allow it once, allow that tool for the session, or reject it and provide feedback. The docs call out a real risk: approving a broad shell tool can allow a wider command shape later than the one you initially saw.

For scripted runs, you can configure approval behavior explicitly:

# Allow git status/log commands, but deny dangerous pushes.
copilot -p "Summarize recent branch activity" 
  --allow-tool='shell(git status)' 
  --allow-tool='shell(git log)' 
  --deny-tool='shell(git push)' 
  --no-ask-user

There are broader flags like --allow-all-tools, --allow-all, and --yolo. They exist for automation, but they are not free. If you use them, assume the agent has the same local power you do. The safer pattern is to allow the smallest set of tools needed for the job and deny operations you never want automated.

Local sandboxing is available via /sandbox enable, and cloud sandboxing can be started with copilot --cloud. GitHub marks cloud and local sandboxes for Copilot as public preview, so I would verify behavior before relying on them for a compliance boundary.

Extensibility: AGENTS.md, Skills, Custom Agents, Plugins, and Hooks

GitHub Copilot CLI is more useful when it knows how your team works. The customization surface is broad now: custom instructions, AGENTS.md, skills, custom agents, plugins, hooks, memory, and LSP configuration.

For repo-wide norms, custom instructions and AGENTS.md are the starting point. GitHub documents .github/copilot-instructions.md, path-specific .github/instructions/*.instructions.md files, local instructions under ~/.copilot, and AGENTS.md files in the repo root or current working directory. If your repository has build rules, commit discipline, API conventions, or security constraints, this is where they belong.

Skills are folders with a SKILL.md file and optional supporting scripts or resources. Use them for specialized workflows that should load only when relevant. A GitHub Actions debugging skill, for example, should not pollute every prompt about C# domain modeling.

Custom agents use .agent.md files and can live in .github/agents/ or ~/.copilot/agents/. They define specialized behavior, tools, and instructions. Plugins can bundle MCP servers, agents, skills, and hooks. Hooks can run at lifecycle points like tool use, which makes them useful for policy enforcement or auditing.

If you have built agentic workflows before, this should feel familiar. The difference is that the Copilot CLI gives you these knobs in the terminal product instead of making you build the whole harness yourself. For deeper custom-agent architecture patterns, the ideas in Advanced GitHub Copilot SDK in C# map nicely to this surface.

Using MCP Servers with GitHub Copilot CLI

Model Context Protocol is a major part of the GitHub Copilot CLI story. GitHub documents that the GitHub MCP server is built into the Copilot CLI, so GitHub-related tools are available without extra setup. Custom MCP servers let you connect the agent to external tools, data sources, and systems.

You can add MCP servers interactively with /mcp add, from the terminal with copilot mcp add, or by editing ~/.copilot/mcp-config.json. The CLI supports local STDIO servers and remote HTTP servers. SSE is still supported for backward compatibility, but GitHub labels it as the deprecated legacy transport in the MCP specification, so I would prefer HTTP for new remote servers. The current docs also mention /mcp search as experimental for registry-based discovery.

# Add a local stdio MCP server from the terminal.
copilot mcp add context7 -- npx -y @upstash/context7-mcp

# List configured MCP servers.
copilot mcp list

The important design point is tool scope. MCP expands what the agent can do, whether that means querying a docs server, browser automation server, database-safe read model, or internal platform API. It also expands the trust surface. Use explicit tool lists where possible, avoid broad secrets in MCP server environments, and combine MCP with --allow-tool or --deny-tool when running headless.

If you are building the MCP side yourself, start with Building MCP Servers and Clients in C#: The Complete Guide. The Copilot CLI is the client experience; MCP is how you give that experience better tools.

Model Selection: Defaults, Available Models, and BYOK

Model selection changes quickly, so treat this section as a snapshot. As of the live npm package page I checked for July 2026, GitHub says Copilot CLI uses Claude Sonnet 4.5 by default. Treat that as a dated snapshot, not a contract -- run /model to see the current options in your account. The GA changelog lists model choice across Anthropic, OpenAI, and Google, including Claude Opus 4.6, Claude Sonnet 4.6, GPT-5.3-Codex, Gemini 3 Pro, and Claude Haiku 4.5 for quick tasks.

In an interactive session, use /model to select a model. In a script, use --model=MODEL. The docs also describe model precedence: a custom agent model can win, then --model, then COPILOT_MODEL, then the persisted config in ~/.copilot/settings.json, then the CLI default.

# Pin a faster model for a bounded summary task.
copilot -p "Summarize the public API surface of this project" -s --model claude-haiku-4.5

# Pin a stronger coding model for a deeper refactor.
copilot -p "Refactor the worker pool to remove the race condition" 
  --model gpt-5.3-codex 
  --allow-tool='write, shell(dotnet test)'

BYOK is also documented. Copilot CLI can connect to OpenAI-compatible endpoints, Azure OpenAI, Anthropic, or local models such as Ollama by setting COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_TYPE, COPILOT_PROVIDER_API_KEY, and COPILOT_MODEL. The model must support tool calling and streaming, and GitHub recommends at least a 128k token context window.

The practical tradeoff is capability versus cost, latency, policy, and reproducibility. Pin models for automation. Use /model interactively when the task changes shape.

Non-Interactive GitHub Copilot CLI in Scripts and CI

The -p or --prompt flag is what makes GitHub Copilot CLI useful outside an interactive terminal session. The CLI runs the prompt and exits. Add -s when you want less decoration and more pipe-friendly output. Add --no-ask-user when automation must not pause for a question.

# Produce a concise test-failure summary for CI logs.
copilot -p "Read the latest test output and summarize only actionable failures" 
  -s 
  --allow-tool='read' 
  --no-ask-user

For CI, I would be conservative. Give the agent read access for summaries and diagnostics before you let it write files or run arbitrary commands. If you do allow execution, prefer exact command approvals like shell(dotnet test) instead of broad shell approval. Use --secret-env-vars for values you want redacted in output, and remember that GITHUB_TOKEN and COPILOT_GITHUB_TOKEN are redacted by default according to the programmatic reference.

There are good uses for headless Copilot CLI: summarizing failed builds, preparing a first-pass issue triage report, or reviewing a branch diff. Risky uses include unsupervised database writes, broad deploy permissions, or automatic pushes. The tool can automate. That does not mean every workflow should be automated.

If your automation work lives in GitHub Actions, the same discipline applies to package publishing and release pipelines. I would pair Copilot CLI with explicit workflow boundaries like the ones you need when creating NuGet packages in .NET.

Using GitHub Copilot CLI on a .NET and C# Codebase

On a .NET codebase, GitHub Copilot CLI works better with concrete validation loops. Do not ask it to "improve the project" and hope it finds the right boundary. Ask it to inspect a failing test, add a focused test, update a specific service, or explain refactor tradeoffs.

A practical .NET prompt includes the target project, the expected test command, and any constraints around public APIs or architecture. If your repo uses solution filters, custom build scripts, Testcontainers, or integration-test fixtures, put that in AGENTS.md or custom instructions so you do not repeat it every session.

copilot -p "In this .NET solution, add a failing xUnit test for the cache expiration bug in src/Cache, then implement the smallest fix. Run dotnet test for the affected test project only." 
  --allow-tool='write' 
  --allow-tool='shell(dotnet test)' 
  --no-ask-user

For C# specifically, I want the agent to respect immutability, nullable annotations, analyzers, and test naming conventions. I also want it to run the smallest useful validation command first. If it cannot run the tests, I want that called out clearly instead of papered over.

This is also where the CLI differs from building your own agentic dev tool. If you want to build a tailored C# CLI agent yourself, Build an AI CLI Developer Tool with GitHub Copilot SDK in C# is the SDK path. If you want the terminal agent GitHub ships, GitHub Copilot CLI is the product path.

GitHub Copilot CLI Compared to Other Terminal Agents

GitHub Copilot CLI now sits in the same category as other agentic terminal tools, including Claude Code and similar coding agents. The useful comparison is where each tool fits your workflow and codebase.

The Copilot CLI advantage is GitHub integration, built-in GitHub MCP access, Copilot subscription alignment, customization, and the broader GitHub agent ecosystem. If your team already works in GitHub issues, pull requests, Actions, and Copilot policy management, that integration is meaningful.

Other terminal agents may have different strengths: model access, UX preferences, extensibility ecosystems, local-first behavior, or specific review workflows. Compare the boring things that matter: approvals, tool constraints, repo instructions, long-context behavior, headless predictability, and change auditability.

For senior developers, tool choice is less important than workflow discipline. Require plans for multi-file changes. Keep permission boundaries tight. Run tests. Review diffs. Document repo conventions. Evaluate agent outputs like human-generated patches.

That is why I like connecting terminal-agent evaluation back to agent measurement. The same ideas behind evaluating AI agents with Microsoft.Extensions.AI.Evaluation in C# apply here: define what good looks like, measure behavior, and do not confuse confidence with correctness.

Wrapping Up: Treat GitHub Copilot CLI Like a Junior-to-Senior Multiplier, Not a Magic Wand

GitHub Copilot CLI is not just a command explainer anymore. It is an agentic terminal coding agent with local workflows, GitHub integration, MCP extensibility, custom instructions, skills, custom agents, model selection, and headless automation.

That is powerful. It is also the reason you should be deliberate. The best outcomes come when you give the Copilot CLI a clear task, a clear repo context, a clear validation command, and a clear permission boundary. Use Standard mode when you want steering. Use Plan mode when scope matters. Use Autopilot only when the guardrails are strong enough.

For .NET and C# teams, the opportunity is real: less context switching, faster investigation, more automated validation, and a terminal-first path for agentic development. But the engineering bar does not move. The agent can help you move faster. You still own the decision.

FAQ

Is GitHub Copilot CLI the same as gh copilot?

No. The old gh copilot GitHub CLI extension is retired. GitHub Copilot CLI now refers to the standalone copilot command. If a guide treats gh copilot suggest as current, it is describing the retired extension.

What is the current npm version of GitHub Copilot CLI?

The live npm registry returned @github/copilot version 1.0.68 when this article was researched in July 2026. Because the CLI ships frequently, run npm view @github/copilot version or copilot version before writing automation around specific behavior.

What is the default model for GitHub Copilot CLI?

The live npm package page stated that GitHub Copilot CLI uses Claude Sonnet 4.5 by default as of July 2026. Treat that as a dated snapshot because availability can depend on plan and organization policy. Use /model to see current options; scripts can also use --model, COPILOT_MODEL, and persisted settings.

Can GitHub Copilot CLI run without interaction in CI?

Yes. Use copilot -p "prompt" for non-interactive mode. Add -s for quieter output and --no-ask-user to prevent pauses. For safety, prefer narrow permissions like --allow-tool='shell(dotnet test)' instead of broad flags such as --allow-all.

Should I use Autopilot mode for production repositories?

Sometimes, but not blindly. Autopilot is useful when the task is bounded and the repository has strong tests, clear custom instructions, and safe permission settings. For broad changes, Plan mode is usually a better first step because it gives you a chance to review the approach before edits happen.

Does GitHub Copilot CLI support MCP servers?

Yes. The GitHub MCP server is built into the CLI, and you can add custom MCP servers with /mcp add, copilot mcp add, or ~/.copilot/mcp-config.json. MCP gives the CLI access to specialized tools, but it also expands your trust surface.

Is GitHub Copilot CLI better than Claude Code?

It depends on the workflow. GitHub Copilot CLI is compelling when GitHub integration, Copilot policies, MCP, skills, custom agents, and GitHub-native pull request workflows matter. Claude Code and other terminal agents may fit different model, UX, or local workflow preferences. Compare them using safety, auditability, repo instruction support, and validation loops instead of brand loyalty.