GitHub Copilot CLI

The terminal is where infrastructure work happens, where Git actually runs, and where the commands that break production get typed.

It is also, for that reason, the surface where an AI agent’s permission model matters most — and GitHub Copilot CLI is the surface where that model is most explicit. It asks before it acts, and it gives you several ways to say what “acting” is allowed to mean.

This cluster treats it as an engineering environment rather than a command explainer.

Start with the Complete Guide

What makes this surface different

It can run things. Chat suggests a command; the CLI can execute it, read the output, and decide what to do next. That loop — act, observe, adjust — is what makes it an agent rather than an assistant.

The permission model is visible. Every tool use that touches your filesystem or runs a command is an approval. You can approve once, for the session, or configure allowances up front with --allow-tool and --deny-tool. The controls are yours and they are legible.

It is where your context already is. The repository, the failing command, the log file, the terraform plan output. No copying and pasting between a browser and a terminal.

It carries repository configuration. Instructions, custom agents, skills, hooks and MCP servers all apply, which means the same customisation that shapes Copilot elsewhere shapes it here.

The permission model is the security story

Everything defensible about running an agent in a terminal comes down to one question: what is it allowed to do without asking?

The CLI’s answer is a tiered one:

• Ask every time — the default for anything touching files or running commands
• Approve for the session — convenient, and scoped to this session
• Pre-approved allowances — --allow-tool='shell(git)' permits a specific class up front
• Explicit denials — --deny-tool refuses regardless
• Allow everything — --allow-all-tools, /allow-all, /yolo

That last row exists because approval fatigue is real. It is also the row that removes the control, and it belongs to throwaway work in a sandbox rather than to a repository that matters.

Generating a command is not authorising it

The distinction this cluster returns to constantly, especially in the DevOps and Kubernetes lessons:

Generating a command is a research activity. The output is a suggestion, and reading it costs seconds.

Authorising it is an engineering decision about a real system, made by you, with knowledge of what that system is doing right now.

An agent that can do the second without the first being deliberate is an agent operating your infrastructure. Nothing about the model’s competence changes whether that is a good idea.

The lessons

1. 01Lesson 1: 01. Complete GuideCopilot as a terminal agent — installation, sessions and slash commands, the permission model, custom agents, skills, hooks, MCP, plugins, and the safety habits that make it usable on real systems.Intermediate → Advanced15 min read
2. 02Lesson 2: 02. Copilot CLI for GitDriving Git with an agent that can run the commands — status and diff explanation, commit preparation, history analysis, merge and rebase help, reflog recovery.Intermediate13 min read
3. 03Lesson 3: 03. Agentic Code ReviewReviewing changes from the terminal — /review and /diff, reviewing files and directories, suggested fixes, command approval during review, and where terminal review fits against pull request review.Intermediate13 min read
4. 04Lesson 4: 04. Copilot CLI for DevOpsUsing a terminal agent on infrastructure work — logs, shell, containers, Terraform, Kubernetes and Actions — with the credential scoping and command safeguards that production work requires.Advanced14 min read
5. 05Lesson 5: 05. Custom AgentsSpecialised agent profiles — the file format and locations, frontmatter fields, tool restrictions, subagents and delegation, worked examples, and why a narrow tool list beats a careful instruction.Advanced13 min read
6. 06Lesson 6: 06. Copilot CLI for BashGenerating and understanding shell — pipelines, quoting, loops, error handling — and reading a generated command before you run it, because shell has no undo.Intermediate11 min read
7. 07Lesson 7: 07. Copilot CLI for TerraformAI on infrastructure as code — generating configuration, reading a plan properly, module and variable design, security review, state safety, and why apply belongs in a pipeline rather than a session.Advanced13 min read
8. 08Lesson 8: 08. Copilot CLI for DockerAI on containers — writing Dockerfiles, debugging builds, reading logs, multi-stage builds, image size, container security and CI integration, with care around the commands that delete.Intermediate → Advanced12 min read
9. 09Lesson 9: 09. Copilot CLI for KubernetesAI on clusters — manifests and Helm, reading events and rollout failures, resource limits and security contexts.Advanced13 min read

Lesson 1 is the environment itself — installation, sessions, permissions, configuration. Lesson 2 applies it to Git, where the safety framing matters most because the destructive commands are the useful ones. Lesson 3 covers reviewing changes before they leave your machine. Lesson 4 is the DevOps overview and the strongest statement of the safeguards. Lesson 5 covers custom agents, which is how you give the CLI a narrow role rather than a general one. Lessons 6 to 9 apply all of it to the four technologies where terminal work is densest: Bash, Terraform, Docker and Kubernetes.

The shape of a session

Enough of the mechanics to make the cluster’s examples legible.

{/* Start an interactive session in the current directory */}
copilot

{/* Non-interactive, with one specific tool class pre-approved */}
copilot -p "Show me this week's commits and summarize them" --allow-tool='shell(git)'

The interactive session is the common case. Inside it, slash commands manage the environment rather than the conversation — a few that recur throughout this cluster:

Command	Does
/help	The current command list, which is the authoritative one
/context	Shows context-window usage — the thing that silently degrades long sessions
/compact	Summarises history to reclaim context
/model	Displays or sets the model
/mcp	Manages MCP server connections
/permissions	Manages permissions and trust settings
/plan	Planning mode for multi-step work
/review	Reviews code changes or a file
/diff	Reviews changes in the current directory
/add-dir	Grants file access to a directory, and loads its skills and agents
/agent	Browse and select available agents
/session	Create, name and manage sessions
/clear	Start a new conversation

Two worth knowing before you need them. /context is how you find out that a long session has filled its window, which presents as the agent getting vaguer rather than as an error. /add-dir is how a monorepo or a sibling repository comes into scope — and it loads that directory’s .github/skills and .github/agents, which is a scope decision as much as a convenience.

The set changes between releases. /help is the current answer; this table is orientation.

Credentials, and what not to give it

The rule, stated plainly:

Do not give an AI agent credentials you would not give a new contractor on their first day.

Concretely:

No standing production credentials. Not in the shell it runs in, not in an environment variable, not in a profile it can read. If a task genuinely needs production access, that is a task for a reviewed, audited pipeline rather than an interactive session.

Read-only where read-only will do. A great deal of useful agent work — diagnosing a failure, explaining a plan, analysing logs — requires no write access at all.

Scoped, expiring tokens. The same standard Pillar 5 applied to every other machine identity.

Know what is in your environment. An agent running in your shell can read your environment variables. Whatever is in there is in scope.

Availability

GitHub Copilot CLI is available on Linux, macOS, and Windows via PowerShell or WSL. Some capabilities — sandboxes among them — are in public preview. Command and slash-command availability changes between releases; run /help for the current set. Confirm the current position in the GitHub Copilot CLI documentation.

Configuring it for a repository

The same repository files that shape Copilot elsewhere shape the CLI, plus two that are largely a CLI and cloud-agent concern.

Instructions — AGENTS.md, .github/copilot-instructions.md, path-specific instructions. Always on, always charged against context.

Custom agents — a narrow persona with its own instructions and restricted tools. The mechanism for “this agent reviews Terraform and cannot edit anything”, covered in Custom Agents.

Agent skills — task knowledge loaded when relevant, from .github/skills/<name>/SKILL.md among other locations. Covered in Agent Skills.

Hooks — shell commands that run deterministically at points in the agent’s lifecycle, from .github/hooks/*.json. The preToolUse event can deny a tool call, which makes hooks the only mechanism here that enforces rather than suggests. Covered in Building Repository AI Agents.

MCP servers — external tools and data. Useful, and an expansion of what the agent can reach. Covered in MCP + GitHub.

The distinction worth carrying: instructions and skills influence behaviour; permissions and hooks constrain it. When something must not happen, the second category is where you put the control.

Prerequisites

Before you start

• The Copilot cluster — instructions and customisation carry over
• Git credentials — what is in your shell already
• Least-privilege GitHub access — the model for agent permissions
• Git troubleshooting with AI — the safety habits, established

When the terminal is the right surface

Not every task belongs here. The CLI earns its place when three things are true.

The context is already in the terminal. A failing command and its output, a git status that surprises you, a kubectl describe full of events. Copying that into a browser loses fidelity and wastes time; the agent can read it directly.

The work is iterative. Run, read the error, adjust, run again. That loop is what an agent is for, and it is painfully slow through a chat window.

The blast radius is bounded. A repository you can reset, a branch you can delete, a local environment. The moment the loop touches something you cannot undo, the calculus changes and the DevOps lesson’s safeguards apply.

Where it is the wrong surface: anything requiring the deliberation of a written plan and a reviewer — that is a pull request. Anything you want a durable record of — sessions are local. And anything you would not want to happen while you were looking away, which is the case for delegation to the cloud agent rather than an interactive session.

Common mistakes

Running with --allow-all-tools because approvals are tedious. It solves the annoyance by removing the control. Narrow allowances — shell(git), shell(npm) — keep the loop fast without giving away the boundary.

Working in a shell with production credentials loaded. The agent inherits your environment.

Approving a destructive command because the explanation sounded right. The explanation is generated by the same system that generated the command.

Assuming a plan means the plan will be followed. Plan mode is genuinely useful for reviewing intent before execution. It is a statement of intent, not a contract.

Letting it run in a directory you have not thought about. /add-dir and the working directory determine what it can read. Both are worth being deliberate about.

Treating agent-run tests as CI. A local test run is evidence. CI running on the pull request is the gate.

After this cluster

The CLI is AI working alongside you on your machine. The next cluster moves to the pull request, where AI reviews work that other people wrote — and where the question becomes how much weight an unaccountable reviewer should carry.

Next cluster — AI Code Review