How to Install and Use GitHub Copilot CLI on Linux

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.

If switching directories mid-session just saved you a relaunch, pass this along to a teammate juggling multiple repos.

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.

If you’ve ever regretted using a broad --allow-all rule, forward this to anyone on your team who’s about to make the same mistake.

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.

If this command list saves you a trip to the docs while working, share it with your team so everyone has the same shortcuts.

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.

If the difference between MCP and LSP finally clicked for you, pass it on to someone who’s still getting the two confused.

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.

If this article helped, share it with someone on your team.