GitHub Copilot CLI: Install, Sign In and Your First Agent Session

GitHub Copilot CLI is Copilot running as an agent in your terminal. You type copilot in a project folder and talk to it: it reads the code, edits files, runs commands after asking you, and works with GitHub itself through a built-in GitHub MCP server, so it can list your pull requests or open an issue as well as change code. It needs an active Copilot subscription, runs on Linux, macOS and Windows (PowerShell or WSL), and installs with npm, WinGet, Homebrew or a script. Below: installing, signing in, a first session, the approval model, the instruction files it reads, adding an MCP server, and where it sits beside Copilot in your editor and the cloud agent.

Before you install

• A Copilot subscription. If your Copilot comes through an organisation or enterprise, an owner can switch the CLI off; if it will not start for you, ask whether the policy is enabled.
• On Windows, PowerShell 6 or later. The older Windows PowerShell 5.1 that ships with Windows is not enough.
• For the npm route only, Node.js 22 or later.

Install it

GitHub’s page on installing Copilot CLI↗ (opens in a new tab) lists four routes. Pick the one that matches how you install other tools:

# Windows (WinGet)
winget install GitHub.Copilot

# macOS and Linux (Homebrew)
brew install --cask copilot-cli

# macOS and Linux (install script)
curl -fsSL https://gh.io/copilot-install | bash

# Any platform with Node.js 22+
npm install -g @github/copilot

• If your ~/.npmrc has ignore-scripts=true, the npm install needs npm_config_ignore_scripts=false in front of it.
• Each route has a prerelease channel if you want new features early; stick to the stable one for a first install.
• To update later, run copilot update in the terminal or /update inside a session. copilot version shows what you have.

Sign in

The first time you run copilot without being signed in, it asks you to use /login. You can also run copilot login from the shell. Both offer a browser flow, the default on a desktop, and a device-code flow, the default on a remote terminal or in CI, where you type a one-time code into a browser elsewhere. For GitHub Enterprise Cloud with data residency, add --host with your hostname.

According to GitHub’s page on authenticating Copilot CLI↗ (opens in a new tab), the token is stored in your operating system’s keychain; on a headless machine with no keychain the CLI offers to keep it in a plain-text file under ~/.copilot/ instead. Environment variables are checked first, in the order COPILOT_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN, so a GH_TOKEN you set for another tool silently takes over from your sign-in. For scripts, use a fine-grained personal access token with the Copilot Requests permission; classic tokens are not supported. /logout removes the local token but does not revoke it on GitHub.

Your first session

1. Change into a repository you know well. Do not start in your home folder: the CLI works in, and below, the folder you launch it from.
2. Run copilot. It asks you to confirm that you trust the files in this folder. Say yes only for a project you would run code from yourself.
3. Run /env to see what loaded; the command reference↗ (opens in a new tab) lists instruction files, MCP servers, skills, agents, hooks, plugins, LSPs and extensions. If your instructions file is missing from the list, fix that before anything else.
4. Ask a read-only question first: “How do I run one test in this repository?” or “What does src/billing do?”. Reading and searching do not need approval, so this costs you nothing to check.
5. Ask for a small change. When it wants to edit a file or run a command, it stops and asks. Read the command before you answer.
6. Review with /diff. If you do not like the result, /undo opens a picker that can roll back the conversation, or the conversation and the files it changed.
7. For anything bigger, press Shift+Tab to switch to plan mode first. Copilot asks clarifying questions and writes a plan before it touches code.

Three shortcuts are worth learning on day one: @ followed by a file name adds that file to the context, ! followed by a command runs it in your shell without going through Copilot, and /context shows how full the context window is. Long sessions are compacted automatically as they approach the limit, and /compact does it on demand.

Approvals and tool permissions

Read-only work is allowed automatically. Anything that can change your system, such as editing a file, running a command that is not read-only or fetching a URL, asks first. The prompt gives you three choices: allow it once, allow that tool for the rest of the session, or refuse and tell Copilot what to do instead. Some prompts also offer “don’t ask again” for the current repository, which is saved to ~/.copilot/permissions-config.json and applies in later sessions there.

You can set permissions when you start, too. GitHub’s page on allowing and denying tool use↗ (opens in a new tab) describes patterns such as shell(git:*) for every git command, write(src/*.ts) for some files, and a server name for an MCP server’s tools. Deny rules always win, even over the allow-all options and over saved approvals.

# Let it use git without asking, but never push
copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

# A one-shot prompt that exits when done; approvals must be given up front
copilot -p "Summarise this week's commits" --allow-tool='shell(git)'

# Start over: forget approvals given in this session and for this location
/reset-allowed-tools

--allow-all (also --yolo, or /allow-all inside a session) lets it use every tool, path and URL without asking. GitHub recommends it only in an isolated environment and warns against making it an alias. If you want more autonomy on your own machine, /sandbox enable turns on local sandboxing, which restricts what commands can reach on the file system and network; it is in public preview.

Instruction files it reads

The CLI reads more instruction files than most Copilot surfaces. GitHub’s page on custom instructions for Copilot CLI↗ (opens in a new tab) lists them:

• Repository: .github/copilot-instructions.md and path-specific .github/instructions/**/*.instructions.md.
• Agent files: AGENTS.md, CLAUDE.md (or .claude/CLAUDE.md) and GEMINI.md, found at the repository root, in the directory you started in and in folders on the path to the files it works on.
• Personal: ~/.copilot/copilot-instructions.md and ~/.copilot/instructions/**/*.instructions.md, for preferences that follow you into every repository.

It combines all of them rather than choosing one, removes exact duplicates, and defines no precedence between them, so two contradictory lines both reach the model. Write each rule once. /instructions shows which files loaded and lets you switch one off, and /init writes a .github/copilot-instructions.md for the repository, or suggests improvements to the one you have. What to put in those files is in copilot-instructions.md examples and AGENTS.md examples; which other Copilot surfaces read which file is in does GitHub Copilot support AGENTS.md?

Adding an MCP server

Four MCP servers are built in and need no setup: github-mcp-server, playwright, fetch and time. For anything else, GitHub’s page on adding MCP servers to Copilot CLI↗ (opens in a new tab) gives two routes: /mcp add inside a session opens a form, or copilot mcp add does it from the shell. Remote servers use --transport http and a URL, local ones take a command after --, and both are saved in ~/.copilot/mcp-config.json. A remote server that signs you in with OAuth opens a browser; if its sign-in expires, /mcp auth followed by the server name starts it again. /mcp list prints what is configured, and /mcp show followed by a server name opens that server’s details and tools. More on each route is in Copilot CLI MCP.

Where it fits next to the editor and the cloud agent

• With VS Code: when you start the CLI in a folder that is open in VS Code, it connects to that window, so the code you select becomes context and proposed edits open as diffs in the editor. /ide manages the connection.
• With the cloud agent: /delegate, or a prompt starting with &, hands the task to Copilot cloud agent on GitHub. GitHub’s page on delegating tasks↗ (opens in a new tab) says it offers to commit your unstaged changes to a new branch as a checkpoint, then the agent works remotely and opens a draft pull request. How the cloud agent works is in the GitHub Copilot coding agent.
• Autopilot keeps the work local: Shift+Tab until the status bar says autopilot, and Copilot carries on without stopping for input. It needs full permissions, so the advice above about isolated environments applies.
• /fleet splits a plan across parallel subagents; when that is worth it is covered in multi-agent setups with GitHub Copilot.

A rough rule: the editor for work you want to watch line by line, the CLI for a task you can describe in a sentence and check with a diff, and the cloud agent for a task you want to hand off and review as a pull request. If you also use Claude Code, Claude Code vs GitHub Copilot compares the two.

Keep the session’s work on a board

A CLI session ends with a transcript, and a transcript is not a record anyone else can read. Connect the CLI to a fenbs board and the work it does becomes tasks with comments, in the same lanes your team uses. Add the server once:

copilot mcp add --transport http fenbs https://fenbs.ai/api/mcp

When the CLI asks you to sign in to the server, fenbs opens in your browser: sign in, tick what it may do (reading the board is always on; adding and changing tasks, and commenting, are your choice) and approve. On a machine with no browser, issue a token under Settings, “Connect an AI assistant”, and add it with --header "Authorization: Bearer YOUR_TOKEN"; revoking it there ends it. Then add one line to AGENTS.md: “Before starting, call fenbs_get_context and read your task with fenbs_get_item; when you stop, comment on it with what changed and move it to Completed only if the tests pass.” To stop being asked about every board call, start the CLI with --allow-tool='fenbs', or allow just the reading tools. Every change it makes is recorded with its name and yours.