GitHub Copilot CLI Commands Cheat Sheet

Every command and flag on this page was read out of a real installation rather than transcribed from documentation. copilot --version reported 1.0.80 on 2026-08-23, installed via npm, and the tables below come from copilot --help, copilot help <topic> and copilot <subcommand> --help on that build.

Find a command by what you are trying to do

Reference pages are organised by structure; work is organised by intent. This index maps the second onto the first.

I want to understand a repository I did not write. Start read-only. Deny write and url, then ask. The explore agent exists for precisely this and cannot modify anything.

I want the agent to fix something. Allow the test runner and local git, leave write on prompt so every file change surfaces, deny shell(git push:*).

I want to script this. -p for one prompt and exit, -s for clean output, --no-ask-user so it cannot stall, and an explicit --allow-tool list.

I want to know why it did that. /diagnose for the session log, /env for what actually loaded, /context for whether it had room to remember.

I want to undo something. /rewind for the last turn’s file changes; git for anything older or anything that left the machine.

I want it to stop doing so much. /plan before implementation, or a mid-session correction naming a specific path boundary.

I want to spend less. /usage to see where it went, --max-ai-credits and --max-autopilot-continues to bound the next run.

I want to hand this off. /delegate sends the session to GitHub and produces a pull request.

Launching

The pairing to remember is -p versus -i. -p is non-interactive: one prompt, one answer, exit. -i opens a normal interactive session that happens to start with your prompt. Scripts want -p; humans in a hurry want -i.

Permissions

This is the section worth reading properly. Everything else in the CLI is convenience; this is the part that decides what can happen to your machine.

Two independent systems

Visibility decides what the model can see:

• --available-tools — a whitelist. Everything not listed is disabled.
• --excluded-tools — a blacklist. Only the listed tools are disabled.

Approval decides what happens when a visible tool is called:

• --allow-tool — run without prompting.
• --deny-tool — refuse, without prompting.
• --allow-all-tools — approve everything automatically.

The pattern grammar

Permissions take the form kind(argument), with the argument optional. Four kinds are documented:

Three details in that grammar cause real mistakes:

:* matches on the command stem. shell(git:*) matches git push and does not match gitea. Approval for git and gh happens per first-level subcommand, which is what makes shell(git status) expressible separately from shell(git push).

Relative paths in write() match trailing components. write(.env) matches a file called .env in any directory, not just the working one. That is usually what you want for a deny rule and rarely what you want for an allow rule. Use an absolute path — write(/srv/app/config.yml) — to pin a rule to one place.

URL patterns are protocol-aware. url(https://example.com) does not permit http://example.com. A pattern with no protocol defaults to https://.

Worked policies

Interactive slash commands

Available inside a running session. The capability badges say what each one can do; the risk column is this curriculum’s judgement, not GitHub’s.

The five worth memorising

Out of that list, five carry most of the day-to-day value:

/env shows what the session actually loaded — instructions, MCP servers, skills, agents, hooks, plugins, LSPs, extensions. When behaviour is inexplicable, this is the first command to run, because the cause is usually a configuration file you forgot existed.

/instructions narrows that to instruction files specifically, and lets you toggle them. Useful when a rule is being applied that you did not write.

/context shows token usage. An agent that has started ignoring earlier constraints is often simply out of room.

/rewind reverts the last turn and its file changes. Narrow, but exactly right for “that was not what I meant”, and worth reaching for before you start manually undoing edits.

/review runs the code review agent over your changes. Covered properly in the code review lesson.

Subcommands

copilot help <topic> is the most valuable of these and the least used. The topics are permissions, sandbox, config, environment, limits, billing, providers, logging, monitoring and commands. They describe the binary you have installed, which — given how fast this tool ships — is frequently ahead of published documentation.

Scripting and automation flags

A non-interactive invocation that behaves predictably usually needs three things beyond the prompt:

copilot -p "Summarise the changes in the last commit" \
  --allow-tool='shell(git:*)' \
  --no-ask-user \
  -s

--allow-tool grants exactly what the task requires. --no-ask-user disables the tool the agent uses to ask a clarifying question — without it, a run can stall waiting for an answer nobody will give. -s suppresses session statistics so stdout is just the response.

Add --output-format json when a program rather than a person reads the output; it emits JSONL, one object per line.

Modes

Three modes, selectable with --mode or toggled in session:

Interactive is the default. The agent proposes; you approve.

Plan (--plan, /plan) produces an implementation plan before writing code. For anything spanning several files, reading a plan is cheaper than reviewing an implementation you disagree with.

Autopilot (--autopilot, /autopilot) proceeds without stopping for approval. --max-autopilot-continues bounds how many times it continues on its own, defaulting to 5.

Combining them is documented: --plan --mode autopilot auto-approves the plan and implements it autonomously. That is a genuinely useful combination in a throwaway environment and a poor one on a working checkout.

Sandboxing

Sandboxing runs shell commands inside an OS-level sandbox with restricted filesystem and network access. It is experimental and disabled by default, and the /sandbox command only exists when experimental features are enabled — otherwise it returns “Unknown command”.

Enable experimental features with --experimental. Host support: macOS via Seatbelt (sandbox-exec), Linux via bubblewrap (needs bwrap 0.5.0+ on PATH), Windows via a process container targeting Windows 11.

Reading the capability badges

Each row in the tables above carries capability labels rather than a colour code, because the distinction they draw is the one that decides whether a command can hurt you.

Read only means the command inspects and reports. /diff, /list-dirs, /context and /usage sit here. They are safe to approve without much thought, and pre-approving them is how you buy back attention for the commands that need it.

Can modify files means the command creates or changes something on disk. /init writes .github/copilot-instructions.md; --share writes a transcript. Neither is dangerous, but both put a file somewhere you will later have to explain in a diff.

Can execute shell is the label that matters. A command with this capability can run anything your account can run, because — with sandboxing off, which is the default — there is no reduced privilege set. /autopilot carries it because it proceeds without asking.

Network access covers commands that reach outside the machine. /share, /research and the URL-permitting flags sit here. These are the effects /rewind cannot reverse.

A command with no badge is one whose effect depends entirely on what you ask it to do, which is most of the interesting ones.

Sessions, context and history

A session is the unit that holds your conversation, the tools you have already approved, the working directory, and whatever the agent has worked out about your repository. Rebuilding that costs time, so the session commands matter more than their placement in a help listing suggests.

--continue picks up the most recent session. -r or --resume accepts a session ID, a task ID, an ID prefix, or a name — name matching is exact and case-insensitive, which is an argument for naming sessions with -n at launch or /rename once a conversation has found its shape. /session lists what exists and manages it.

/fork splits the current session in two. The value is not obvious until the first time you have spent twenty turns establishing context and want to try two approaches from it: forking preserves that investment for both attempts instead of forcing you to choose.

/compact summarises conversation history to reclaim context window, and takes focus instructions so you can say what the summary must preserve. /context shows current usage, and --context selects a tier at launch — default or long_context.

The practical sequence is worth stating: when an agent begins ignoring an instruction it previously followed, check /context first. Context exhaustion looks exactly like disobedience, and rewriting the instruction does not fix it.

/rewind reverts the last turn and the file changes it made. It is the right reflex when the agent has just done something unintended, and it is narrow — it does not reach back many turns, and it cannot undo an effect that left your machine. A push that succeeded stays pushed.

Talking to GitHub

Because the CLI holds a GitHub session, several commands reach past your working directory.

/pr operates on pull requests for the current branch. /delegate hands the session to GitHub, where the coding agent continues and opens a pull request; --base selects the target branch. That combination — start locally where you can steer, delegate once the remaining work is mechanical — is one of the genuinely new workflows this tool enables.

/share exports a session to a Markdown file, an HTML file, a gist, or a shareable GitHub link. In non-interactive runs the same job is done by --share[=path] and --share-gist.

A GitHub MCP server is built in, with a default subset of tools enabled. --add-github-mcp-tool and --add-github-mcp-toolset extend that selectively; --enable-all-github-mcp-tools opens the full set and overrides the narrower flags. --disable-builtin-mcps turns the built-in servers off entirely.

Cost and limits

Agentic sessions consume AI credits, and an autonomous run consumes them while you are not watching. Four controls exist.

/usage reports session metrics and statistics. /limits opens the limits dialog, or sets one directly — /limits set max-ai-credits <credits>. --max-ai-credits does the same at launch. --max-autopilot-continues caps how many continuation messages autopilot will send itself, defaulting to 5.

GitHub describes the AI credit limit as a soft cap. Read that word carefully: it is a guardrail against a loop that has gone wrong, not a billing guarantee. Session limits apply across the current conversation, and /clear or /new resets used credits while keeping the configured limit until you unset it.

copilot help billing and copilot help limits carry the current detail.

Logging and diagnosis

Logs land in ~/.copilot/logs/ unless --log-dir says otherwise. --log-level takes none, error, warning, info, debug, all or default.

/diagnose analyses the current session log and accepts a custom prompt, which makes it the quickest answer to “why did it decide to do that”. For fleet-scale or long-running use, copilot help monitoring documents OpenTelemetry support.

Recipes

A handful of invocations that cover most real use.

Read a repository without any risk of changing it. The strongest version of this is denial rather than restraint, because a denied tool cannot be approved by a tired human:

copilot --deny-tool='write' --deny-tool='url' -i "Explain how this project is structured"

Run the test suite and fix what fails, without publishing.

copilot --allow-tool='shell(pytest:*)'         --allow-tool='shell(git:*)'         --deny-tool='shell(git push:*)'         -i "Find and fix the failing tests"

Get a machine-readable answer for a script.

copilot -p "List every TODO comment with its file and line"         --allow-tool='shell(rg:*)' --no-ask-user -s --output-format json

Give the agent one extra directory rather than the whole filesystem.

copilot --add-dir ../shared-library -i "Compare our API client with the shared one"

Pin behaviour for a run you intend to repeat. Auto-update means today’s invocation may not behave like tomorrow’s, so a repeatable job should pin the model and decline updates:

copilot --no-auto-update --model <model> -p "..." --allow-tool='shell(git:*)' -s

Where configuration comes from

The CLI discovers configuration from several locations. Knowing which is which saves a lot of confusion when behaviour does not match the file you just edited.

--no-custom-instructions disables instruction loading entirely. disableAllHooks disables every hook, repository and user level alike.

Instruction precedence, per GitHub’s documentation: personal instructions rank highest, then repository, then organisation — but all relevant sets are provided to Copilot rather than one replacing another. The custom instructions lesson works through what that means in practice.

Flags that look similar and are not

Four pairs account for most of the mistakes people make with this surface.

--allow-tool and --allow-all-tools. One grants named tools; the other grants everything. They are eleven characters apart and a world apart in effect. Shell completion helps here more than care does.

--allow-tool and --available-tools. Approval versus visibility. A tool excluded from --available-tools cannot be re-granted with --allow-tool, because the model never sees it. If a permission rule appears to be ignored, this is the first thing to check.

-p and -i. Both take a prompt. -p runs it and exits; -i starts an interactive session with it. A script written with -i will hang waiting for a human.

--plan and --mode plan. Equivalent for starting in plan mode, but --mode also accepts autopilot, and the documented combination --plan --mode autopilot auto-approves the plan and implements it. Reading that as “plan mode, therefore safe” is a mistake — the combination is the least supervised configuration available.

Environment variables

Several behaviours are configurable from the environment, which matters most in CI where flags are awkward to thread through.

COPILOT_GITHUB_TOKEN, GH_TOKEN and GITHUB_TOKEN supply authentication, in that order of precedence. COPILOT_ALLOW_ALL is the environment equivalent of --allow-all-tools. COPILOT_DISABLE_TERMINAL_TITLE suppresses the terminal title updates.

copilot help environment documents the full set on your installation, and is worth reading once — the environment surface is easier to miss than the flag surface and is what most CI configuration actually uses.

A note on keeping this current

Copilot CLI ships frequently, and a cheat sheet is exactly the kind of page that rots quietly. Two habits make it survivable.

Record the version any instructions were written against — this page names 1.0.80 at the top for that reason. And when something does not match, check copilot --version and /changelog before assuming the documentation is wrong; /changelog summarize produces an AI summary of what moved between versions.

Printing this

This page is set up for printing, and a printed cheat sheet beside a keyboard is a reasonable way to learn a large flag surface.

If you do print it, write the version at the top by hand. This page names 1.0.80 because a reference that does not say what it describes is a reference that will quietly mislead someone in six months — and a printed copy has no way of telling you it has gone stale.

Next

The beginner tutorial puts these commands into a working sequence. The pillar explains the model the permission flags implement. For applying them to real work, the DevOps lesson builds least-privilege policies for infrastructure tools, and the GitHub Actions lesson does the same for CI.