GitHub Copilot CLI: How to Use an AI Coding Agent in Linux Terminal

If you’ve used Copilot inside a code editor, Copilot CLI works a little differently. It runs as a standalone agent in your shell, can read your actual repository, and can plan changes, edit files, and run commands for you—with your approval at each step.

What Is GitHub Copilot CLI

GitHub Copilot CLI is a terminal-native AI agent from GitHub, using the same agentic engine as GitHub’s Copilot coding agent so that it can do more than answer questions. From the copilot command in your terminal, it can read your codebase, suggest changes, edit files, run shell commands, and even open pull requests.

This guide was tested on Ubuntu 26.04 LTS and Fedora 42. However, the commands should work on most modern Linux distributions because Copilot CLI is distributed as a single binary without distro-specific dependencies.

Copilot CLI also includes GitHub’s MCP server, letting you work with issues and pull requests in plain English. You can also connect custom MCP servers to extend what Copilot CLI can do. By default, it asks for your approval before taking actions, unless you explicitly configure it to work without approval.

Prerequisites

You’ll need an active GitHub Copilot subscription because copilot requires one for authentication. You’ll also need either curl or Node.js with npm, depending on the installation method you choose below.

If your organization provides Copilot through your work account, an organization owner or enterprise administrator can disable Copilot CLI even if your regular Copilot access works elsewhere. If you run into a policy-related login error, check with your administrator first.

How to Install GitHub Copilot CLI on Linux

There are three ways to install copilot on a Linux system. Choose the method that best fits your existing setup. All three methods install the same binary.

Method 1: Install Script

This is the quickest option if you don’t already have Node.js installed. The script detects your system, downloads the appropriate binary, and places it on your PATH.

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

Here’s what each part of the command does:

• curl downloads the installation script from GitHub’s short link.
• -fsSL makes curl fail on server errors, suppresses the progress output, and follows redirects, which the short link requires.
• | bash sends the downloaded script directly to bash for execution.

By default, the installer places the files in $HOME/.local when run as a non-root user, or /usr/local when run as root. If you want Copilot CLI available to all users on a shared server, prefix the command with sudo. This gives the installation script temporary root privileges so it can write to /usr/local/bin.

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

You can also pin a specific release and choose a custom installation directory using the VERSION and PREFIX environment variables. This is useful when you want every machine in a team to use the same Copilot CLI version.

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

Method 2: Install with npm

If Node.js and npm are already installed on your system, this is a simple one-line installation and makes it easy to update Copilot CLI later with npm update -g.

npm install -g @github/copilot

The -g option installs the package globally instead of placing it in a local node_modules directory. This makes the copilot command available from any directory.

If you already use Homebrew on Linux, you can install Copilot CLI through the same package manager:

brew install copilot-cli

Homebrew also provides copilot-cli@prerelease if you want to try experimental features before they reach the stable release.

Verify the Installation

After installing Copilot CLI using any of the three methods, confirm that the copilot command is available and check the installed version:

copilot --version

If your shell returns command not found: copilot, the installation directory is probably not included in your PATH. This is one of the most common installation issues, and it often happens when $HOME/.local/bin is missing from your shell configuration.

You can add it to your current session with:

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

To make the change permanent, add the same line to ~/.bashrc or ~/.zshrc, depending on the shell you use. Then reload the configuration:

source ~/.bashrc

Authenticating GitHub Copilot CLI

Copilot CLI needs to authenticate your GitHub account before you can use it. Start the CLI for the first time with:

copilot

If you’re not already logged in, Copilot CLI will prompt you to run /login. Enter /login in the interactive session and follow the instructions. You’ll be guided through a device-code login flow in your browser.

Authenticate with a Personal Access Token

If you’re working on a headless server without a browser, or using Copilot CLI in a CI pipeline, the device-code flow may not be practical. In that case, you can authenticate with a fine-grained personal access token. Create a token from GitHub’s personal access token settings:

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

When configuring the token, make sure you enable the Copilot Requests permission. Without this permission, the token may authenticate successfully, but Copilot requests will fail with a permissions error.

Set the token in the GH_TOKEN environment variable:

export GH_TOKEN=""

Replace with the actual token generated by GitHub. Copilot CLI checks GH_TOKEN first and uses GITHUB_TOKEN if GH_TOKEN is not set.

Using GitHub Copilot CLI in Your Terminal

Start copilot from the project directory you want it to work with rather than from your home directory. By default, it limits file access to the current directory and its subdirectories.

cd ~/projects/my-app copilot

Once you’re inside the session, 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 and explains what it finds. If it needs to run a command or modify a file, it shows you what it plans to do and asks for your approval. You can approve it once, allow it for the rest of the session, or deny it.

Copilot CLI uses Claude Sonnet 4.5 by default for reasoning. You can run /model inside a session to open the model picker and choose alternatives such as Claude Sonnet 4 or GPT-5. You can also switch models while working on a task without losing your conversation history.

If a task requires access to files outside your starting directory, Copilot CLI asks for permission the first time it tries to access that location. You can also change the working directory without restarting the session:

/cwd ~/projects/another-app

This is useful when you’re working across multiple repositories and don’t want to quit and relaunch Copilot each time.

Controlling What Copilot CLI Can Touch

This is the part worth paying attention to. By default, Copilot CLI asks for your approval before running shell commands or editing files. This is the safest way to use it while you’re getting familiar with how it works.

You can pre-approve specific types of actions with --allow-tool and block specific actions with --deny-tool. Both options use the Kind(argument) pattern, and the argument is optional.

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

Here’s what these options do:

• --allow-tool 'shell(git:*)' pre-approves Git commands that match the git command pattern. The :* suffix matches Git subcommands such as git pull and git status without matching unrelated commands such as 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 remains true even if you use --allow-all in the same command, helping prevent a broad allow rule from accidentally approving a potentially destructive action.

Common Mistake: Reaching for –allow-all Too Soon

--allow-all (also available as --yolo) skips approval prompts for tools, file paths, and URLs. It may seem convenient for repetitive tasks, but it also means Copilot can run commands such as rm, push changes to a remote repository, or modify files you didn’t intend to include without asking you first.

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

Useful Slash Commands

A few slash commands cover most of what you’ll use day-to-day inside an interactive Copilot CLI session.

• /login authenticates your GitHub account if you haven’t already.
• /model lets you switch between Claude Sonnet 4.5, Claude Sonnet 4, and GPT-5.
• /cwd or /cd changes the working directory without restarting the session.
• /allow-all or /yolo grants full approval for the rest of the current session.
• /reset-allowed-tools removes all permissions you’ve granted and returns to the approval settings from when you started the session.
• /feedback opens a short form for submitting feedback or reporting a bug directly from the CLI.
• /help shows all available slash commands. Since new commands are added over time, it’s the most up-to-date reference.

Configuring LSP and MCP Servers

Copilot CLI doesn’t include language servers, so features such as go-to-definition require a language server to be installed separately. For example:

npm install -g typescript-language-server

You can register the language server in ~/.copilot/lsp-config.json to use it across projects, or in .github/lsp.json to configure it for a specific repository. Use /lsp inside a Copilot CLI session to see which language servers are currently active.

MCP servers work in a similar way, but they provide access to external tools and services rather than language intelligence. GitHub’s MCP server is built into Copilot CLI. If you need additional services such as Slack, a database, or another external tool, you can configure persistent third-party MCP servers in ~/.copilot/mcp-config.json.

Conclusion

You now know how to install GitHub Copilot CLI on Linux using the install script, npm, or Homebrew, authenticate it with either the device flow or a personal access token, and control which commands and directories it can access before giving it real work.

Start by trying Copilot CLI in a low-stakes repository. You can run:

copilot --allow-tool='read'

This lets Copilot explore and explain your code without making changes. Spend some time getting familiar with its suggestions before approving write operations or shell commands.

Are you using Copilot CLI with the default approval prompts, or have you already set up --allow-tool rules for your workflow? Tell us what you’ve allowed and what you’re still cautious about in the comments below.