Quick Answer
If you want to start using GitHub Copilot CLI today, the shortest safe path is this:
- Install Copilot CLI with
npm install -g @github/copilotorbrew install copilot-cli. - Start
copilotinside the repo you actually want to work in, use/loginthe first time, and trust the folder for the current session before you decide to remember it. - Stay in interactive mode for exploration, switch to plan mode before code changes, and use programmatic mode only for narrow one-shot tasks.
If the last tutorial you saw skipped the folder-trust prompt, plan mode, or approval settings, treat it as incomplete. GitHub's current beginner guide and quickstart now put those steps directly in the first-run flow, and they matter more than the install command because they define what Copilot can read, edit, and run.
Who This Tutorial Is For
This guide is for developers who already work in the terminal and want Copilot to help with repo exploration, small code changes, Git tasks, and scoped automation without handing it full control of the machine.
Use this setup if you want to:
- stay inside the terminal instead of bouncing between browser, IDE, and shell
- ask Copilot to inspect a repo, explain changes, or draft code with context
- keep approvals tight when Copilot wants to write files or run commands
- learn the new Copilot CLI rather than the older GitHub CLI Copilot extension
If You Read an Older Guide, Check These First
Three details in GitHub's current docs change how you should set up the CLI:
- GitHub now teaches the standalone
copilotcommand and documents both the interactive interface and the-pprogrammatic interface in About GitHub Copilot CLI. - First launch includes a folder-trust step. The quickstart and usage guide both say Copilot may read, modify, and execute files in and below that folder for the session.
- Plan mode and
/delegateare documented product flows now, not hidden tricks. GitHub covers plan mode in About GitHub Copilot CLI and/delegatein the delegate guide.
If an older walkthrough stops at "install and log in," it misses the step where most beginners make mistakes: the first time Copilot asks what it is allowed to touch.
What You Need Before Installation
| Requirement | What to check | Why it matters |
|---|---|---|
| Copilot access | an active GitHub Copilot plan or seat | Copilot CLI will not authenticate without access |
| Node.js 22+ | required only for the npm install path | older Node versions break the documented npm install flow |
| PowerShell 6+ on Windows | needed for the Windows path | GitHub documents Windows support through PowerShell or WSL |
| Org policy | check if your org or enterprise disabled Copilot CLI | enterprise policy can block CLI use even if you have a seat |
As of 2026-04-13, GitHub's Copilot plans page shows Free, Pro at $10/month, and Pro+ at $39/month for individual Copilot plans. The practical takeaway is simpler than the pricing table: you do not need a premium plan just to try the CLI, but you do need an active Copilot entitlement, and the install guide says an organization or enterprise policy can still block the feature.
The Fastest Safe Setup
Step 1: Pick one install method
GitHub's install guide documents four installation paths: npm, Homebrew, WinGet, and a direct install script.
For most developers, the two cleanest options are:
npm install -g @github/copilot
or on macOS and Linux:
brew install copilot-cli
If your ~/.npmrc contains ignore-scripts=true, the same guide documents this npm variant instead:
npm_config_ignore_scripts=false npm install -g @github/copilot
My recommendation:
- use
brew install copilot-cliif you already update shell tools withbrew upgrade - use
npm install -g @github/copilotif Node.js 22+ is already installed and you want the same path across macOS, Linux, or Windows - skip the install script unless package managers are not an option
Step 2: Launch it, authenticate once, and choose the safe trust option
After installation, start the interactive interface with:
copilot
On the first run, use:
/login
GitHub's authentication guide says OAuth device flow is the default and recommended path for interactive use. If you prefer a non-interactive setup, GitHub also documents environment-variable authentication with COPILOT_GITHUB_TOKEN, GH_TOKEN, or GITHUB_TOKEN, and says a fine-grained PAT must include the Copilot Requests permission.
Use the token path when you are in CI, containers, or another headless setup. For a laptop-first setup, /login is simpler.
After login, Copilot asks whether you trust the files in the current folder. GitHub's getting started guide, usage guide, and configuration guide all make the scope clear: during the session, Copilot may read, modify, and execute files in and below that directory.
You will usually see three choices:
Yes, proceedfor the current session onlyYes, and remember this folder for future sessionsNo, exit
The safe beginner default is simple:
- choose the session-only option when you are testing Copilot in a new repo or unfamiliar checkout
- choose the remember option only for directories you control and use repeatedly
- do not start Copilot from your home directory or from a folder that mixes code with secrets, credentials, or unrelated client files
If you need files outside the current repo later, GitHub documents /add-dir and /cwd as safer ways to expand scope than launching Copilot from a broad parent directory.
Step 3: Start in interactive mode, not automation mode
GitHub Copilot CLI now has two user interfaces:
- interactive mode for ongoing back-and-forth work in the terminal
- programmatic mode for one prompt that runs and exits
For a first session, interactive mode is the better default because you can see what Copilot is trying to do before you grant permissions.
A strong first prompt is:
Give me an overview of this project. Show the main entry points, likely build command, test command, and one risky area to avoid touching first.
This works because it forces Copilot to read before it edits.
Step 4: Switch to plan mode before code changes
One of the most useful 2026-era changes is that plan mode is now a documented part of the product.
GitHub's CLI overview and usage guide both say you can use plan mode inside the interactive interface and switch modes with Shift+Tab. You can also use /plan in normal mode.
For example:
/plan Add a new REST endpoint for category listing without changing the current response format.
Why plan mode is the right default for real repos:
- it asks clarifying questions before writing code
- it makes scope visible before file edits start
- it reduces the chance that Copilot quietly turns a small change into a repo-wide rewrite
If you only remember one habit from this tutorial, make it this one: use plan mode first whenever the task touches more than one file.
Step 5: Use programmatic mode only for narrow tasks
GitHub's programmatic guide describes a programmatic interface using -p or --prompt. That same guide recommends minimal permissions, so programmatic mode is best when you want one result and then an exit.
Example:
copilot -p "Summarize the last 5 commits in this repository" --allow-tool='shell(git log:*)'
This is a good fit for:
- commit summaries
- quick repo inspection
- one-shot documentation rewrites
- bounded Git queries
This is a bad fit for:
- open-ended feature implementation
- risky refactors
- anything where you have not decided the approval boundary first
GitHub explicitly warns in its CLI overview and tool-permissions guide that broad automatic approval flags can give Copilot the same file and shell access that you have. Treat that as a real security boundary, not boilerplate legal text.
A Good First Session Order
For your first real repo session, keep the order boring:
| Stage | What you ask Copilot CLI to do | What you check before continuing |
|---|---|---|
| Explore | explain the repo structure, scripts, and recent changes | whether the file map and commands are actually correct |
| Plan | propose a structured implementation plan | whether the scope is acceptable before any edit starts |
| Execute | make the narrow approved change | whether the diff stayed inside the plan |
| Verify | run tests or summarize failures | whether the checks actually passed |
| Delegate | offload a bounded task in the background | whether the resulting branch or PR is worth keeping |
If you keep that order, Copilot reads before it writes, and you stay in review mode instead of cleanup mode.
Three Prompts Worth Copying
1. Repo onboarding prompt
Read this repository and give me:
1. the main entry points
2. the build and test commands
3. the folder I should read first
4. one risky area where changes could have side effects
Do not write code.
2. Safe planning prompt
/plan Add a new CLI flag to this tool.
Constraints:
- preserve existing output format
- do not add dependencies
- list tests before implementation
3. One-shot terminal summary
copilot -p "Show me what changed in package.json and explain whether it affects build or runtime behavior" --allow-tool='shell(git diff:*)'
These three prompts work well because they force the same sequence: inspect first, plan second, automate last.
Common Mistakes and How to Avoid Them
Mistake 1: Starting Copilot from the wrong directory
The first avoidable mistake happens before you type a prompt: launching copilot from a broad parent folder, your home directory, or a workspace full of unrelated files.
Fix: start inside the repo you actually mean to work on. If you need more scope later, use /add-dir or /cwd instead of trusting a huge directory up front.
Mistake 2: Giving broad approvals too early
The fastest way to create avoidable damage is to let Copilot run wide shell access before you know how it behaves in your repo.
Fix: approve the smallest useful tool scope first. Use targeted patterns such as a specific git read command before you approve broader write or shell access.
Mistake 3: Skipping plan mode on multi-file work
Copilot is much easier to trust when you can review a plan before it edits the repo.
Fix: if the task spans multiple files, use /plan first.
Mistake 4: Assuming installation failed when the real problem is policy
GitHub's install guide notes that organization or enterprise policy can disable Copilot CLI even for users who otherwise have Copilot access.
Fix: if login or usage looks blocked, check entitlement and policy before reinstalling.
Mistake 5: Missing the Node.js version requirement
GitHub's install guide currently requires Node.js 22 or later for the npm path.
Fix: if npm install -g @github/copilot fails on an older machine, switch to Homebrew or update Node first.
When /delegate Is Actually Worth Using
GitHub's current docs position /delegate as a handoff to Copilot cloud agent on GitHub, not as a local background worker. The delegate guide says it pushes your current session to GitHub, may ask to commit unstaged changes as a checkpoint in a new branch, and then opens a draft pull request for the cloud agent to continue in the background.
Use /delegate when a GitHub-visible branch and draft PR are part of the outcome. Do not use it when all you want is more local thinking time.
That makes sense for:
- documentation updates
- isolated cleanup tasks
- issue-driven work with a clear acceptance check
It is a weaker fit for:
- active debugging
- exploratory refactors
- anything where you still need to discover the problem
A good beginner rule is simple: delegate only the tasks you could describe clearly in one paragraph and would be comfortable turning into a draft PR.
FAQ
Do I need to leave the terminal to use GitHub Copilot effectively?
No. That is the point of Copilot CLI. The practical value is that repo reading, planning, Git tasks, and bounded code work can all happen in the shell.
Should I remember a folder on first run?
Usually no. Pick the session-only trust option first, especially in a new repo or a mixed workspace. Save permanent trust for directories you control and revisit often.
Should beginners use interactive mode or programmatic mode first?
Start with interactive mode. It gives you more chances to steer, reject, and correct before Copilot touches files or commands.
Is Copilot CLI safe to run with automatic approvals?
Only if you deliberately want Copilot to have broad access in that environment. GitHub's own docs warn that broad auto-approval gives Copilot the same shell and file power that you already have.
If You Copy One Routine
Open the target repo, run copilot, log in, choose session-only trust, ask for a repo overview, switch to plan mode before edits, and widen tool permissions only when the task clearly justifies it. That routine is enough to get useful output without letting the session sprawl.
Verification Note
Verified on 2026-04-13. Topic trigger checked against the official GitHub Blog beginner guide. Installation methods, Node.js 22+ for npm, PowerShell 6+ on Windows, and org-policy limitations checked against Installing GitHub Copilot CLI. OAuth /login, environment-variable authentication, token precedence, and the Copilot Requests PAT permission checked against Authenticating GitHub Copilot CLI. Trusted-folder prompts, interactive usage, and session-only versus future-session trust checked against Getting started with GitHub Copilot CLI, Using GitHub Copilot CLI, and Configure GitHub Copilot CLI. Plan mode and approval-boundary warnings checked against About GitHub Copilot CLI and Allowing and denying tool use. Programmatic -p usage checked against Running GitHub Copilot CLI programmatically. /delegate checkpoint, branch, and draft-PR behavior checked against Delegate tasks to GitHub Copilot CLI. Current individual plan references checked against GitHub Copilot plans.