If you're trying to install GitHub Copilot CLI today, the first thing to know is that this is the standalone copilot terminal agent, not the retired gh copilot extension. The setup path is pretty straightforward, but there are a few choices that matter: package manager vs npm, auto-update vs manual update, OAuth vs token-based auth, and how much trust you give the directory where your first session starts.
Heads up: GitHub Copilot CLI moves fast. It went GA in February 2026 and ships updates constantly, so commands, flags, and install behavior change often. Everything here was verified against the CLI as of July 2026 -- always check the official GitHub Copilot CLI installation docs for the very latest.
For .NET developers on Windows, I think the most practical path is PowerShell 7 plus WinGet, unless you already standardize your workstation tools through npm. For macOS and Linux developers, Homebrew or the install script is usually the least friction. The important part is not picking the fanciest install path. It's picking one that fits how you keep developer machines updated.
Before You Install GitHub Copilot CLI: Prerequisites That Matter
Before you install GitHub Copilot CLI, make sure the account and shell prerequisites are in place. GitHub's docs list an active GitHub Copilot subscription as required. If your access comes through an organization or enterprise, an owner or administrator also needs to allow Copilot CLI in policy settings.
On Windows, GitHub documents PowerShell v6 or higher as a prerequisite. In practice, that means I would use PowerShell 7 (pwsh) for a .NET development workstation. It is cross-platform, current, and avoids the weirdness of older Windows PowerShell defaults. Windows Subsystem for Linux is also supported, but that is a separate environment from your normal Windows shell, so install and authenticate intentionally in the environment where you plan to work.
# Confirm the shell version before installing on Windows.
$PSVersionTable.PSVersion
# Confirm Node only if you plan to use the npm install path.
node --version
If you're using npm, Node.js 22 or later is required. That requirement is specific to the npm path. WinGet, Homebrew, the install script, and direct executables don't require you to manage a global Node runtime just to get the copilot command on your PATH.
This is also a good time to decide where you'll run your first session. Copilot CLI asks whether you trust the current directory because it may read, modify, and execute files under that folder during the session. Don't start from your profile directory just because your terminal opens there. Start from the repository you actually want the agent to inspect.
That directory-trust model lines up with how I think about agentic tools in general. If you want a broader mental model for tool boundaries and agent execution, my article on Getting Started with Microsoft Agent Framework in C# covers why scope and control points matter when agents can call tools.
Install GitHub Copilot CLI with npm, WinGet, Homebrew, Script, or Download
There are five official ways to install GitHub Copilot CLI as of July 2026: npm, WinGet, Homebrew, the macOS/Linux install script, and direct downloads from GitHub releases. They all install the copilot command. The tradeoff is mostly about update behavior and how your team manages developer machines.
# npm, all platforms. Requires Node.js 22 or later.
npm install -g @github/copilot
# Windows with WinGet.
winget install GitHub.Copilot
# macOS or Linux with Homebrew.
brew install --cask copilot-cli
The npm path is convenient if your workstation is already Node-first or if you want the same command across Windows, macOS, and Linux. The tradeoff is that npm installs are manual from an update perspective. To update through npm, rerun the global install command when you want the latest package. The current @github/copilot npm package I verified during this session was version 1.0.68, with 1.0.69-2 on the prerelease tag.
WinGet is the path I would usually recommend for a Windows + PowerShell 7 .NET machine. It fits naturally with Windows workstation setup, and the GitHub GA changelog states that WinGet installations automatically update. That matters because Copilot CLI changes quickly, and stale clients are a real source of confusion when someone follows current docs but their local binary behaves differently.
Homebrew is the natural option for macOS and Linux if you already use it. GitHub documents the cask command as brew install --cask copilot-cli, and the Homebrew cask page reported version 1.0.68 during verification. GitHub's GA changelog also states that Homebrew installations automatically update.
For macOS and Linux machines where you don't use Homebrew, the install script is official too:
# macOS and Linux install script.
curl -fsSL https://gh.io/copilot-install | bash
# Equivalent wget form.
wget -qO- https://gh.io/copilot-install | bash
The script installs to $HOME/.local for a non-root user by default, or /usr/local when run as root. You can set PREFIX to choose the install location and VERSION to pin a version. GitHub's GA changelog says install-script installations automatically update, so this can be a reasonable fleet-style path for Linux development environments.
Direct download is the most explicit option. The install docs point to the GitHub copilot-cli releases page, where you can download an executable archive or installer for your platform, unpack it, and run it. During live verification, the latest GitHub release was v1.0.68, with Windows x64 zip and MSI assets, macOS tarballs, Linux tarballs, and musl builds. I would use direct download when you need a specific binary artifact for a locked-down machine or image build.
Choosing the Right copilot cli install Path for a .NET Workstation
The best copilot cli install path depends on how you update the rest of your tools. That's the MOFU decision point: you're not just asking whether the install command works. You're deciding which maintenance model you want to own.
For an individual Windows developer using PowerShell 7, WinGet is the most natural fit. You don't need Node just to install GitHub Copilot CLI, the package ID is clear, and automatic updates reduce the odds of debugging behavior from an old client. The downside is that WinGet availability depends on the Windows Package Manager being present on the machine. Some locked-down corporate images need that enabled or installed first.
For a Node-heavy team, npm is simple and predictable. npm install -g @github/copilot is easy to script, easy to document, and cross-platform. But the npm path requires Node.js 22 or later, and update discipline sits with you. If half the team updates weekly and half never updates, you can end up with inconsistent CLI behavior across the same repository.
For macOS and Linux, Homebrew has a similar advantage to WinGet: it fits an existing package-management workflow and GitHub says it auto-updates for Copilot CLI. The install script is useful when you don't want Homebrew, especially in Linux environments where $HOME/.local/bin is part of the user's PATH. Direct download gives you the most control, but also the most responsibility.
I would avoid mixing install methods on the same machine. If you install through npm and then later install with WinGet, your shell may find whichever copilot appears first on PATH. That's not a Copilot-specific problem, but it becomes annoying fast when you're trying to figure out why copilot version reports something different than expected.
# After installation, verify which executable your shell finds.
Get-Command copilot
# Then confirm the installed CLI version.
copilot version
This is the same general tooling hygiene I recommend for .NET SDKs, package managers, and CLIs. If you're building more AI tooling yourself, the distinction between a product CLI and an SDK matters too. I covered that angle in GitHub Copilot SDK for .NET: Complete Developer Guide, where the SDK is something you build with, while Copilot CLI is something you operate directly.
Authentication After You Install GitHub Copilot CLI
Once you install GitHub Copilot CLI, authentication is the next gate. GitHub documents three main authentication methods in the official Copilot CLI authentication guide: OAuth device flow, environment variables, and GitHub CLI fallback. For a normal first session, use OAuth. For CI or a container, use environment variables with a supported token. GitHub CLI fallback is convenient, but it's the lowest-priority method.
Interactive OAuth can start inside the CLI with /login or outside it with copilot login. Both use a device flow. The CLI gives you a one-time code and directs you to https://github.com/login/device; then you authorize GitHub Copilot CLI in the browser and return to the terminal.
# Option A: authenticate before starting the interactive session.
copilot login
# Option B: start the CLI, then enter this slash command inside it.
copilot
/login
For GitHub Enterprise Cloud with data residency, copilot login accepts a host argument. Most individual GitHub.com users won't need that, but it matters for enterprise setups where authentication targets a *.ghe.com host.
# Enterprise Cloud with data residency example.
copilot login --host https://example.ghe.com
GitHub's authentication docs say the CLI stores OAuth credentials in the operating system keychain when available. On Windows, that means Credential Manager. On macOS, Keychain Access. On Linux, libsecret-backed keyrings such as GNOME Keyring or KWallet. If a keychain is unavailable, the CLI may prompt to store the token in plaintext under ~/.copilot/config.json, which is a tradeoff you should treat carefully on shared or headless machines.
For non-interactive environments, GitHub documents this precedence order: COPILOT_GITHUB_TOKEN, then GH_TOKEN, then GITHUB_TOKEN, then the stored OAuth token, then GitHub CLI fallback. A fine-grained personal access token must be owned by your personal account and include the Copilot Requests account permission. Classic ghp_ personal access tokens are not supported by Copilot CLI.
# CI/container style example. Keep real tokens out of source control.
$env:COPILOT_GITHUB_TOKEN = 'github_pat_...'
copilot -p "Summarize the repository layout" -s
That example is intentionally shallow. Headless automation deserves its own treatment because approval flags, secret handling, output shaping, and policy boundaries can get subtle. Here, the important setup point is that token auth exists, fine-grained PATs are the supported PAT path, and classic PATs are not.
If you're also building CI around .NET packages, keep the auth model separate from your publishing credentials. The same pipeline might use Copilot CLI for analysis and GitHub Actions for deployment, but those should not casually share tokens. My writeup on Automating NuGet Package Publishing with GitHub Actions goes deeper on pipeline boundaries from a .NET packaging angle.
First Launch: Trust the Directory Before You Start Working
After you install GitHub Copilot CLI and authenticate, launch it from the repository where you want help. The official getting-started docs show copilot as the interactive entry point. On first launch from a folder, Copilot asks whether you trust the files in that location.
You can proceed for the current session only, remember the folder for future sessions, or exit. I like that this prompt exists because it forces a small but important pause. The CLI can operate on files under the trusted directory, and it may request permission to run tools that modify or execute files. Trust should be an explicit choice, not a side effect of wherever your terminal happened to open.
# Start in the repository, not in your home directory.
Set-Location C:devyour-dotnet-repo
copilot
For a first successful session, keep the prompt low-risk. Ask Copilot to explain the repository, identify the solution files, or summarize the test projects. You're validating that install, auth, directory trust, and basic context discovery all work before asking it to edit anything.
Give me an overview of this project. Identify the main solution file, web project, test projects, and the smallest safe validation command.
That prompt stays inside this spoke's scope: first launch, first success, no deep interactive mechanics. You're not asking Copilot to change code yet. You're proving the CLI can start, authenticate, understand the working directory, and produce useful context. For .NET repos, I want the first response to mention the .sln or .slnx, project folders, test projects, and likely commands such as dotnet test or a targeted test project.
If you're using Copilot CLI in a repository with strong local conventions, make sure those conventions are documented. The CLI supports repository instructions, including AGENTS.md and .github/copilot-instructions.md, but this setup article does not need to cover customization in depth. The practical point is simple: the agent performs better when your repo tells it how to build, test, and avoid dangerous operations.
This overlaps with broader software architecture discipline. If an AI agent is going to reason through your codebase, structure and boundaries help. The ideas in Building AI Agents with Semantic Kernel in C# are still relevant when the reader of your code is an agent-assisted workflow instead of just another human.
What a Successful Setup Looks Like
A successful setup is not just "the command launches." After you install GitHub Copilot CLI, I would consider the first session successful when five things are true.
First, copilot version returns a current version and points to the install method you expect. Second, copilot login or /login completes and shows your GitHub account. Third, you start from a repository folder and make a deliberate trust decision. Fourth, Copilot can answer a low-risk project overview prompt. Fifth, you know how the CLI will be updated on that machine.
For a quick self-check, I would expect this setup state:
copilot versionreports the expected client.Get-Command copilotresolves to the package manager you intended.- OAuth or token auth is active for the right GitHub account.
- The trusted directory is the repository, not a broad home folder.
- The first prompt succeeds without asking Copilot to edit files.
That last point is easy to skip, but it matters. GitHub's GA changelog says WinGet, Homebrew, and install-script installations automatically update. npm is the manual path, so plan to rerun npm install -g @github/copilot when you want the current release. Direct downloads are explicit by nature, so they fit pinned environments more than fast-moving personal workstations.
For teams, I would document the chosen path in the repo or onboarding guide. Don't make every developer rediscover this. A short setup section with the install command, required shell, auth guidance, and first validation prompt is enough. If your team builds agentic developer tools internally, you might also find Build an AI CLI Developer Tool with GitHub Copilot SDK in C# useful for thinking about what belongs in your own automation versus what you can delegate to the product CLI.
Common Setup Mistakes When You Install GitHub Copilot CLI
The most common mistake is following old gh copilot guidance. That extension was a different product experience and is not what this article is about. If a tutorial tells you to use gh copilot suggest or gh copilot explain, treat it as stale for the current GitHub Copilot CLI workflow.
The second mistake is installing with npm on a machine that does not have Node.js 22 or later. If you don't otherwise need Node on a Windows .NET workstation, WinGet is usually simpler. If you do use npm, make sure you're comfortable with manual updates.
The third mistake is launching from a directory that's too broad. Starting from C:UsersNick or your home directory on macOS/Linux gives the agent the wrong scope. Start from the repository. Trust the repository. Keep the operating boundary tight.
The fourth mistake is using the wrong token type for CI or containers. Fine-grained PATs with Copilot Requests are supported. Classic ghp_ tokens are not supported. Environment variable precedence can also surprise you, especially if GH_TOKEN is already set for another tool and silently overrides the OAuth token you expected Copilot CLI to use.
The fifth mistake is assuming install and authorization prove readiness for automation. They don't. They prove the CLI can run. Before you use Copilot CLI in deeper workflows, decide which tools it can run, which paths it can access, and what validation it must perform. That conversation belongs with your team's engineering standards, not just with an install command.
FAQ
How do I install GitHub Copilot CLI on Windows?
Use PowerShell 7 or another supported PowerShell v6+ shell and run winget install GitHub.Copilot. That is the Windows package-manager path documented by GitHub, and GitHub's GA changelog says WinGet installations automatically update.
How do I install GitHub Copilot CLI with npm?
Run npm install -g @github/copilot on a machine with Node.js 22 or later. The npm package is named @github/copilot, and the installed command is copilot. Use this path if npm is already part of your workstation management story.
Is npm install -g @github/copilot automatically updated?
No. Treat npm as the manual update path. If you install GitHub Copilot CLI with npm, rerun npm install -g @github/copilot when you want the latest release, or use a package-management process that handles global npm updates for you.
Can I use copilot login instead of /login?
Yes. GitHub documents both. Use copilot login from your terminal before the interactive session, or start copilot and enter /login inside the CLI. Both use the OAuth device flow for interactive authentication.
What token should I use for CI authentication?
Use COPILOT_GITHUB_TOKEN, GH_TOKEN, or GITHUB_TOKEN, in that precedence order. The token can be a fine-grained personal access token with the Copilot Requests account permission. Classic ghp_ personal access tokens are not supported by Copilot CLI.
What should I ask in my first GitHub Copilot CLI session?
Ask for a repository overview before asking for edits. A good first prompt is: "Give me an overview of this project. Identify the main solution file, web project, test projects, and the smallest safe validation command." That proves setup, auth, trust, and basic repo context without changing files.
Final Takeaway
Install GitHub Copilot CLI with the method that matches how you maintain your machine. For Windows + PowerShell 7 .NET development, WinGet is a strong default. For cross-platform npm shops, npm install -g @github/copilot is simple but manual to update. For macOS and Linux, Homebrew or the install script keeps the setup lightweight, and direct downloads are there when you need a pinned artifact.
Once installation is done, don't rush into code edits. Authenticate with /login or copilot login, start from the repository you actually trust, accept the directory prompt deliberately, and make your first successful session a read-only project overview. That's the setup foundation I want before letting an agentic terminal tool anywhere near a real .NET codebase.