GitHub Copilot CLI

The power of GitHub Copilot, now in your terminal.

GitHub Copilot CLI brings AI-powered coding assistance directly to your command line, enabling you to build, debug, and understand code through natural language conversations. Powered by the same agentic harness as GitHub's Copilot coding agent, it provides intelligent assistance while staying deeply integrated with your GitHub workflow.

See our official documentation for more information.

🚀 Introduction and Overview

We're bringing the power of GitHub Copilot coding agent directly to your terminal. With GitHub Copilot CLI, you can work locally and synchronously with an AI agent that understands your code and GitHub context.

• Terminal-native development: Work with Copilot coding agent directly in your command line — no context switching required.
• GitHub integration out of the box: Access your repositories, issues, and pull requests using natural language, all authenticated with your existing GitHub account.
• Agentic capabilities: Build, edit, debug, and refactor code with an AI collaborator that can plan and execute complex tasks.
• MCP-powered extensibility: Take advantage of the fact that the coding agent ships with GitHub's MCP server by default and supports custom MCP servers to extend capabilities.
• Full control: Preview every action before execution — nothing happens without your explicit approval.

We're still early in our journey, but with your feedback, we're rapidly iterating to make the GitHub Copilot CLI the best possible companion in your terminal.

📦 Getting Started

Supported Platforms

• Linux
• macOS
• Windows

Prerequisites

• (On Windows) PowerShell v6 or higher
• An active Copilot subscription. See Copilot plans.

If you have access to GitHub Copilot via your organization or enterprise, you cannot use GitHub Copilot CLI if your organization owner or enterprise administrator has disabled it in the organization or enterprise settings. See Managing policies and features for GitHub Copilot in your organization for more information.

Installation

Install with the install script (macOS and Linux):

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

Or

wget -qO- https://gh.io/copilot-install | bash

Use | sudo bash to run as root and install to /usr/local/bin.

Set PREFIX to install to $PREFIX/bin/ directory. Defaults to /usr/local when run as root or $HOME/.local when run as a non-root user.

Set VERSION to install a specific version. Defaults to the latest version.

For example, to install version v0.0.369 to a custom directory:

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

Install with Homebrew (macOS and Linux):

brew install copilot-cli

brew install copilot-cli@prerelease

Install with WinGet (Windows):

winget install GitHub.Copilot

winget install GitHub.Copilot.Prerelease

Install with npm (macOS, Linux, and Windows):

npm install -g @github/copilot

npm install -g @github/copilot@prerelease

npm release publishing

The npm release workflow runs when a GitHub release is published. It downloads only the nine already-built npm assets: npm-github-copilot-${VERSION}.tgz and npm-github-copilot-${VERSION}-${PLATFORM}.tgz for each of the eight supported platforms. It ignores the older github-copilot-*.tgz launcher tarballs and validates the nine new assets' names, SHA-256 digests, package identities, versions, platform metadata, and launcher dependencies before publishing anything. It does not build from or execute release-tag code. Run the workflow manually on main with the exact published release_tag to recover a missed or failed release event; releases without all nine new npm assets are rejected even on manual recovery. Matching versions are skipped only when their npm dist.integrity matches the release tarball. Older releases use a version-specific release-<version> npm tag if latest or prerelease has advanced, so recovery never intentionally downgrades those channels. A version already on npm with a missing/stale channel tag fails closed: npm OIDC cannot perform npm dist-tag add, so an npm administrator must repair that tag separately. The npm dist-tag recheck cannot prevent a concurrent publisher from advancing a tag between the read and npm publish --tag; the cutover requires exclusive ownership of these packages' channel tags.

Required setup before cutover: On npmjs.com, configure an npm trusted publisher with npm publish permission for each of the nine packages: @github/copilot, @github/copilot-darwin-arm64, @github/copilot-darwin-x64, @github/copilot-linux-arm64, @github/copilot-linux-x64, @github/copilot-linuxmusl-arm64, @github/copilot-linuxmusl-x64, @github/copilot-win32-arm64, and @github/copilot-win32-x64. Set organization/user to github, repository to copilot-cli, and workflow filename to publish-npm.yml (the exact repository is github/copilot-cli); leave environment unset. Use GitHub-hosted runners. The workflow uses Node 24, npm >= 11.5.1 and id-token: write, with no NPM_TOKEN or NODE_AUTH_TOKEN. The runtime repository must continue its existing publishing until this workflow is merged and all nine npm trusted publishers are configured. At cutover, disable the old runtime publish-cli.yml workflow, wait for all its in-progress and queued runs to finish, then merge the runtime workflow change. Retire any other publisher of these nine packages and prohibit reruns of older runtime release runs. Only then set the CLI_NPM_RELEASE_CUTOVER_COMPLETE repository Actions variable to true in github/copilot-cli and re-enable the updated runtime workflow. Without this variable the new workflow fails before any npm publish, including manual recovery. If an external publisher is restarted, unset the variable before publishing another release; a dist-tag read is not a concurrency lock. Its internal Azure feed publication and ancillary release tasks remain separate. The release artifact producer must attach the nine actual npm package tarballs under the new npm-github-copilot- names before cutover. Older releases such as v1.0.90-4 contain only the legacy launcher-manifest tarballs and cannot be recovered through this workflow.

Launching the CLI

copilot

On first launch, you'll be greeted with our adorable animated banner! If you'd like to see this banner again, launch copilot with the --banner flag.

If you're not currently logged in to GitHub, you'll be prompted to use the /login slash command. Enter this command and follow the on-screen instructions to authenticate.

Authenticate with a Personal Access Token (PAT)

You can also authenticate using a fine-grained PAT with the "Copilot Requests" permission enabled.

1. Visit https://github.com/settings/personal-access-tokens/new
2. Under "Permissions," click "add permissions" and select "Copilot Requests"
3. Generate your token
4. Add the token to your environment via the environment variable GH_TOKEN or GITHUB_TOKEN (in order of precedence)

Using the CLI

Launch copilot in a folder that contains code you want to work with.

By default, copilot utilizes Claude Sonnet 4.5. Run the /model slash command to choose from other available models, including Claude Sonnet 4 and GPT-5.

Experimental Mode

Experimental mode enables access to new features that are still in development. You can activate experimental mode by:

• Launching with the --experimental flag: copilot --experimental
• Using the /experimental slash command from within the CLI

Once activated, the setting is persisted in your config, so the --experimental flag is no longer needed on subsequent launches.

Experimental Features

• Autopilot mode: Autopilot is a new mode (press Shift+Tab to cycle through modes), which encourages the agent to continue working until a task is completed.

Each time you submit a prompt to GitHub Copilot CLI, your monthly quota of premium requests is reduced by one. For information about premium requests, see About premium requests.

For more information about how to use the GitHub Copilot CLI, see our official documentation.

🔧 Configuring LSP Servers

GitHub Copilot CLI supports Language Server Protocol (LSP) for enhanced code intelligence. This feature provides intelligent code features like go-to-definition, hover information, and diagnostics.

Installing Language Servers

Copilot CLI does not bundle LSP servers. You need to install them separately. For example, to set up TypeScript support:

npm install -g typescript-language-server

For other languages, install the corresponding LSP server and configure it following the same pattern shown below.

Configuring LSP Servers

LSP servers are configured through a dedicated LSP configuration file. You can configure LSP servers at the user level or repository level:

User-level configuration (applies to all projects): Edit ~/.copilot/lsp-config.json

Repository-level configuration (applies to specific project): Create .github/lsp.json in your repository root

Example configuration:

{
  "lspServers": {
    "typescript": {
      "command": "typescript-language-server",
      "args": ["--stdio"],
      "fileExtensions": {
        ".ts": "typescript",
        ".tsx": "typescript"
      }
    }
  }
}

Viewing LSP Server Status

Check configured LSP servers using the /lsp command in an interactive session, or view your configuration files directly.

For more information, see the changelog.

📢 Feedback and Participation

We're excited to have you join us early in the Copilot CLI journey.

We're building quickly. Expect frequent updates--please keep your client up to date for the latest features and fixes!

Your insights are invaluable! Open an issue in this repo, join Discussions, and run /feedback from the CLI to submit a confidential feedback survey!