GitHub Copilot CLI on Linux: install, auth, and first prompts

Published September 7, 2026

A command line interface showing the text ubuntu@ubuntu:~$ sudo with a blinking cursor

GitHub Copilot CLI is not just autocomplete in a different location. It is a terminal-native AI agent that reads your actual repository, plans changes, edits files, runs shell commands, and can open pull requests. Every action requires your approval by default, which is the right default.

This guide covers installation on Linux, authentication for both interactive and headless environments, and the permission controls worth understanding before you hand the agent real write access. Tested on Ubuntu 26.04 LTS and Fedora 42. The commands work on most modern Linux distributions because Copilot CLI ships as a single binary with no distro-specific dependencies.

You need an active GitHub Copilot subscription. If your organization manages Copilot access, an organization owner or enterprise administrator can disable the CLI even if your regular Copilot access works fine elsewhere. A policy-related login error is worth checking with your admin before debugging anything else.

Table of Contents

️ Three Ways to Install Copilot CLI

All three methods install the same binary. Pick the one that fits your current setup.

Method 1: Install script

The fastest option if you do not already have Node.js. The script detects your system, downloads the right binary, and puts it on your PATH.

curl -fsSL https://gh.io/copilot-install | bash

The flags do specific work here: -f fails on server errors, -s suppresses progress output, -S still shows errors when silent mode is active, and -L follows the redirect the short link requires.

By default, a non-root install goes to $HOME/.local. A root install goes to /usr/local. To make Copilot CLI available to all users on a shared server, prefix with sudo:

curl -fsSL https://gh.io/copilot-install | sudo bash

To pin a specific version and set a custom install directory, use the VERSION and PREFIX environment variables. This is useful when you want every machine on a team running the same release:

curl -fsSL https://gh.io/copilot-install | VERSION="v0.0.369" PREFIX="$HOME/custom" bash

Method 2: npm

If Node.js and npm are already on your system, this is one line and makes updates straightforward later with npm update -g:

npm install -g @github/copilot

The -g flag installs globally so the copilot command is available from any directory, not just the project where you ran the install.

Method 3: Homebrew

If you already use Homebrew on Linux:

brew install copilot-cli

Homebrew also offers copilot-cli@prerelease if you want to test features before they hit the stable release.

Verify the install

After any of the three methods, confirm the binary is reachable:

copilot --version

Green computer code text scrolling on a dark screen during a software installation

If you get command not found: copilot, the install directory is not on your PATH. This is the most common issue, and it usually means $HOME/.local/bin is missing from your shell config. Add it to the current session:

export PATH="$HOME/.local/bin:$PATH"

To make it permanent, add that line to ~/.bashrc or ~/.zshrc, then reload:

source ~/.bashrc

Authentication

Interactive login (device flow)

Start the CLI from the terminal. If you are not logged in, it will prompt you to run /login. Enter /login in the interactive session and follow the browser-based device-code flow.

copilot

Headless authentication (personal access token)

If you are on a server without a browser, or running Copilot CLI in a CI pipeline, the device flow will not work. Create a fine-grained personal access token at:

https://github.com/settings/personal-access-tokens/new

Enable the Copilot Requests permission when configuring the token. Without it, the token will authenticate but Copilot requests will return a permissions error.

Set the token as an environment variable:

export GH_TOKEN="<your-token>"

Copilot CLI checks GH_TOKEN first and falls back to GITHUB_TOKEN if GH_TOKEN is not set.

Running Your First Session

Start Copilot CLI from the project directory you want it to work with. By default, it limits file access to the current directory and its subdirectories.

cd ~/projects/my-app
copilot

Describe what you want in plain English. For example:

Explain what this bash deploy script does and flag anything that looks unsafe

Copilot CLI reads the relevant files, explains what it finds, and shows you exactly what it plans to do before touching anything. You can approve once, allow for the rest of the session, or deny.

The default model is Claude Sonnet 4.5. Run /model inside a session to open the model picker and switch to Claude Sonnet 4 or GPT-5. You can change models mid-task without losing your conversation history.

To change the working directory without restarting the session:

/cwd ~/projects/another-app

⚙️ Controlling What Copilot CLI Can Touch

By default, the CLI asks for approval before running shell commands or editing files. That default is intentional. Before you loosen it, understand the two flags that shape what the agent can actually do.

Use --allow-tool to pre-approve specific action types and --deny-tool to block specific actions. Both use the Kind(argument) pattern:

copilot --allow-tool 'shell(git:*)' --deny-tool 'shell(git push)'

--allow-tool 'shell(git:*)' pre-approves Git commands matching the git pattern. The :* suffix matches subcommands like git pull and git status without matching unrelated commands like gitea.
--deny-tool 'shell(git push)' blocks git push specifically, even though the broader git:* rule would otherwise allow it.

Deny rules always take priority over allow rules. This holds even if you combine a deny rule with --allow-all in the same command.

The case against –allow-all

--allow-all (also available as --yolo) skips approval prompts for tools, file paths, and URLs. It seems convenient for repetitive tasks. It is also how you end up with Copilot running rm or pushing changes to a remote without asking.

Use --allow-all only in sandboxed or disposable environments, not in your main working directory.
For repetitive low-risk commands, use narrow rules like --allow-tool='shell(npm test)' instead.
Run /reset-allowed-tools inside a session to strip all permissions granted so far and return to approval prompts.

Slash Commands Reference

These cover most of what you will use day-to-day inside an interactive session:

/login: authenticate your GitHub account
/model: switch between Claude Sonnet 4.5, Claude Sonnet 4, and GPT-5
/cwd or /cd: change working directory without restarting the session
/allow-all or /yolo: grant full approval for the rest of the current session
/reset-allowed-tools: remove all permissions granted and return to startup settings
/feedback: submit feedback or report a bug directly from the CLI
/help: list all available slash commands, the most current reference as new commands are added

LSP and MCP Configuration

Copilot CLI does not include language servers. Features like go-to-definition require a separately installed language server. For TypeScript:

npm install -g typescript-language-server

Register it globally in ~/.copilot/lsp-config.json or per-repository in .github/lsp.json. Run /lsp inside a session to see which language servers are currently active.

MCP servers extend Copilot CLI with access to external tools and services rather than language intelligence. GitHub’s MCP server is built in, which means you can work with issues and pull requests in plain English from the start. For additional services like Slack or a database, configure persistent third-party MCP servers in ~/.copilot/mcp-config.json. You can also connect custom MCP servers to extend what Copilot CLI can do beyond the defaults.

Start Here Before You Trust It

Before approving any write operations or shell commands, run Copilot CLI in read-only mode on a low-stakes repository:

copilot --allow-tool='read'

This lets it explore and explain your code without making changes. Spend time reviewing its suggestions in that mode before expanding permissions. The approval prompts exist for a reason, and the permission model is granular enough that you do not need to choose between full control and full automation.

Cagri Sarigoz( Founder )

I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.

With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.

At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.

And more than all else, I’m a father to a (always) little girl and a husband.

Contact me at [email protected] for assistance.