GitHub Copilot CLI Best Practices

GitHub Copilot CLI is no longer a small “ask the terminal a shell command” tool. GitHub now describes it as a terminal-native AI coding assistant with agentic capabilities: it can read code, edit files, run commands, manage pull requests, call subagents, connect MCP and LSP servers, run in autopilot, and expose a running local session through GitHub.com or GitHub Mobile.

The best way to use it is not to maximize autonomy. It is to build a supervised workflow around it.

What Copilot CLI Is Good At

Copilot CLI is strongest on repository-level work, not line-level autocomplete.

Good fits:

• understanding an unfamiliar codebase
• planning an implementation
• making small to medium cross-file changes
• adding tests and fixing test failures
• running lint, type checks, and local commands
• reviewing code and managing pull requests
• generating reports, summaries, and documentation
• delegating bounded work to background agents

Poor fits:

• precise one-line editor work
• vague “refactor the whole system” requests
• direct production operations
• exploratory work that needs constant human steering
• changes you are not prepared to review

Treat it as an engineering teammate with terminal access, not an unsupervised developer.

Setup: Update The Old Assumptions

Current GitHub docs list these practical prerequisites:

• an active GitHub Copilot plan
• Copilot CLI enabled by the organization or enterprise if Copilot is provided by work
• Node.js 22 or later when installing with npm
• PowerShell v6 or later on Windows

Common installation paths:

# npm, cross-platform
npm install -g @github/copilot

# macOS / Linux
brew install copilot-cli

# Windows
winget install GitHub.Copilot

# macOS / Linux install script
curl -fsSL https://gh.io/copilot-install | bash

Useful maintenance commands:

copilot login
copilot version
copilot update
copilot logout

Start it inside a repository:

copilot

On first launch, Copilot asks whether you trust the current directory. Take that seriously. During a CLI session, Copilot may read, modify, and execute files in and below that directory.

Start With Custom Instructions

The most important setup step is not picking a model. It is giving Copilot durable project guidance.

Run:

copilot init

Or inside an interactive session:

/init

Copilot analyzes the codebase and writes or updates .github/copilot-instructions.md. That file should hold information Copilot cannot reliably infer from the repository but should follow every time.

Example:

# Build and validation
- Run `pnpm test` after TypeScript logic changes.
- Run `pnpm lint` before finishing.
- Run `pnpm prisma generate` after schema changes.

# Constraints
- Do not change public API response shapes without approval.
- Do not add production dependencies unless requested.
- Do not push to remote branches unless explicitly asked.

# Patterns
- Follow `src/orders/validation.ts` for request validation.
- Follow `src/jobs/send-digest.ts` for background jobs.

Supported instruction locations include:

Keep these files short and operational. Commands, constraints, directories, and reference patterns help. Generic rules like “write high-quality code” do not.

Tool Permissions: Separate Visibility From Authorization

Copilot CLI can run shell commands, read and write files, search the codebase, fetch web content, use MCP tools, and delegate work to subagents. Read-only operations are usually allowed automatically; write operations, destructive commands, and URL access require approval unless pre-authorized.

There are two layers:

1. Tool availability: whether the model can even see a tool.
2. Tool permission: whether the chosen tool can run without asking.

Restrict the tool set:

# Block web search and web fetch entirely
copilot --excluded-tools='web_fetch, web_search'

# Expose only common local code tools
copilot --available-tools='bash,edit,view,grep,glob'

Allow or deny specific actions:

# Allow Git commands, but never push
copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

# Allow reads, and writes only to one instructions file
copilot --allow-tool='read, write(.github/copilot-instructions.md)'

# Deny all writes
copilot --deny-tool=write

Important: deny rules take precedence over allow rules, even with --allow-all.

Use these sparingly:

copilot --allow-all-tools
copilot --allow-all
copilot --yolo

GitHub explicitly recommends using full-permission modes only in isolated environments. Do not make --yolo your default alias.

If a session accumulates too many permissions, reset them:

/reset-allowed-tools

Write Prompts As Executable Tasks

A useful Copilot CLI prompt should include:

• Goal: what should change
• Context: files, errors, issues, pull requests, or reference implementations
• Constraints: what must not change
• Done when: tests, lint, diff expectations, or acceptance criteria

Weak:

fix checkout

Better:

Goal:
Reduce duplicate payment validation in src/checkout/.

Context:
- Follow the pattern in src/orders/validation.ts.
- The failing test is checkout-expired-card.test.ts.

Constraints:
- Do not change public API response shapes.
- Do not add production dependencies.

Done when:
- Checkout unit tests pass.
- Final answer lists changed files and remaining risks.

Structured prompts reduce guessing and make the final diff easier to review.

Use Plan Mode Before Hard Work

GitHub’s best-practices guide emphasizes Plan mode: Copilot creates a structured implementation plan before writing code.

Use:

/plan Add OAuth2 authentication with Google and GitHub providers

Or press Shift+Tab in the interactive UI to toggle plan mode. The plan is saved to plan.md in the session folder, and you can press Ctrl+Y to edit it in your Markdown editor.

Use Plan mode for:

• new features
• cross-file refactors
• database migrations
• authentication, billing, permissions, or audit logic
• CI/CD and deployment scripts
• requirements you have not fully clarified

A stable flow:

1. Read the relevant files. Do not edit yet.
2. /plan ...
3. Review the plan and tighten scope.
4. Approve implementation.
5. Run tests and lint.
6. Use /review on the diff.

Plan mode is useful because it catches wrong direction before code is written.

Autopilot Is For Clear Boundaries

Autopilot lets Copilot keep working through multiple steps after the initial instruction. It stops when the task is complete, blocked, interrupted, or when it hits --max-autopilot-continues.

Good fits:

• implementing an approved plan
• adding tests
• fixing CI failures
• simple refactors
• bounded scripts with clear inputs and outputs

Poor fits:

• open-ended exploration
• vague feature work
• product or architecture decisions that need human judgment
• production operations

Programmatic example:

copilot --autopilot --max-autopilot-continues 10 \
  --allow-tool='shell(npm:*), shell(git:*), write' \
  --deny-tool='shell(git push)' \
  -p "Run the test suite, fix failures in src/auth/, and summarize the diff."

Autopilot and --allow-all are different things. Autopilot is a continuation mode. --allow-all is a permission decision. Combining them increases risk.

Use /fleet Only For Independent Work

/fleet lets the main agent split a task into independent subtasks and run them in parallel with subagents.

Good fits:

• tests for independent modules
• review of separate directories
• several unrelated documentation updates
• alternative plan exploration

Poor fits:

• multiple agents editing the same files
• sequential migrations
• tasks depending on an unsettled shared abstraction

Example:

/fleet Write unit tests for src/users, src/orders, and src/payments.
Each subtask owns only its directory. Do not edit shared test helpers.
Run the relevant test command for each module and summarize failures.

The core rule: define ownership. Parallelism only helps when write scopes do not collide.

Bring Review And PR Work Into The Loop

Copilot CLI includes a code-review agent. Use /review before you ask a human to spend attention:

/review the changes on this branch compared to main.
Focus on correctness, security, regression risk, and missing tests.
Do not comment on style unless it hides a bug.

Pull request commands:

/pr
/pr create
/pr fix feedback
/pr fix conflicts
/pr fix ci
/pr auto

GitHub’s docs note that commands such as /pr fix feedback, /pr fix conflicts, /pr fix ci, and /pr auto may commit and push. Keep your tool policy strict enough that you still approve those actions.

Practical loop:

1. Implement locally.
2. Run tests.
3. /review the branch.
4. Create or update the PR.
5. Use /pr fix ci for failing checks.
6. Human-review the high-risk changes.

Add MCP, LSP, Skills, And Agents Carefully

Copilot CLI is extensible. That does not mean every extension should be installed on day one.

MCP: external tools and context

MCP connects Copilot CLI to external tools, data sources, and services. The GitHub MCP server is built in; other MCP servers can be added with /mcp add or configuration files.

Use MCP when:

• issue, PR, or CI state lives in GitHub
• requirements live in Linear or Jira
• docs live in an internal knowledge base
• operations data lives outside the repository
• the agent needs to call a tool, not just read pasted text

Add one high-value MCP workflow first. Expand after it proves useful.

LSP: code intelligence for large repos

LSP servers give Copilot CLI structured operations such as go-to-definition, find references, hover, rename, document symbols, and workspace symbol search.

This matters for large TypeScript, Go, Python, Java, and similar repositories where text search is not enough. If you ask Copilot to rename symbols or understand type relationships, configure LSP early.

Skills and custom agents

Skills capture repeatable methods:

• PR review checklists
• release note drafting
• migration planning
• incident summaries
• dependency upgrade review

Custom agents capture roles:

• test writer
• security reviewer
• documentation maintainer

Start with custom instructions. Promote repeatable workflows into skills or agents only after they are stable.

Model Choice: Prefer Principles Over Static Lists

GitHub’s supported model list changes frequently by client, plan, policy, and region. Do not hard-code old model tables into team docs.

Useful rules:

• Use Auto or the current CLI default for routine work.
• Switch to stronger models for complex refactors, debugging, and architecture.
• Use lighter models for summaries, search, and simple docs.
• In scripts and CI, set --model explicitly for repeatability.
• Use /model to see available models and premium request multipliers.

If you bring your own model provider, GitHub’s BYOK docs require tool calling/function calling and streaming. For best results, use a context window of at least 128k tokens. Configuration uses variables such as COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_TYPE, COPILOT_PROVIDER_API_KEY, and COPILOT_MODEL.

Document variable names only. Never commit real keys.

Rubber Duck: Experimental Second Opinion

GitHub introduced Rubber Duck for Copilot CLI in experimental mode in April 2026. It uses a complementary model family as an independent reviewer at high-value checkpoints: after planning, after complex implementation, or before running tests.

Use it for:

• complex refactors
• high-risk architecture changes
• test coverage review
• checking a plan before implementation

Current caveats:

• it is experimental
• enable experimental features with /experimental
• availability depends on model access
• it supplements testing and human review; it does not replace them

When available, it is useful because it adds a different critique source instead of asking the same model to grade its own work.

Programmatic And GitHub Actions Usage

Run a one-off prompt:

copilot -p "Explain this file: ./complex.ts"

echo "Explain this file: ./complex.ts" | copilot

Useful options:

Example:

copilot -p '/review the changes on this branch compared to main. Focus on bugs and security issues.' \
  -s --allow-tool='shell(git:*)'

In GitHub Actions, install the CLI, set COPILOT_GITHUB_TOKEN, and run copilot -p .... GitHub’s docs show this with a fine-grained PAT that has the “Copilot Requests” permission stored as an Actions secret.

Automation guidance:

• be precise
• grant minimum permissions
• set timeouts
• capture output in artifacts or step summaries
• do not let vague prompts modify code and push unattended

Remote Sessions For Long Tasks

Remote access lets you view and steer a running local Copilot CLI session from GitHub.com or GitHub Mobile. This is useful when a long task needs periodic permission approval or you leave your workstation.

Inside a session:

/remote

At startup:

copilot --remote

It is currently public preview. The local machine must stay online, the session must keep running, and the working directory must be a GitHub.com-hosted repository. For long runs, combine it with /keep-alive so the machine does not sleep.

A Stable Daily Workflow

Use this default loop:

1. Run copilot init and maintain .github/copilot-instructions.md.
2. Describe the task with goal, context, constraints, and done conditions.
3. Use /plan for complex changes.
4. Approve implementation only after the plan is scoped.
5. Use Autopilot only for bounded work.
6. Use /fleet only when write scopes are independent.
7. Run tests, lint, and type checks.
8. Use /review before human review.
9. Use /pr for PR status and fixes, but keep commit/push approval explicit.
10. Move repeated corrections into instructions, skills, or agents.

Common Anti-Patterns

Anti-Pattern 1: Default Yolo

Do not alias copilot to copilot --yolo. Full permissions should be rare and isolated.

Anti-Pattern 2: No Instructions File

If you keep repeating build commands, lint commands, architecture rules, or commit conventions in prompts, they belong in .github/copilot-instructions.md.

Anti-Pattern 3: Autopilot For Ambiguous Work

Autopilot is for executing clear plans. It is not a product discovery tool.

Anti-Pattern 4: Parallel Agents On The Same Files

/fleet helps when work is independent. It creates merge pain when several agents edit the same surface.

Anti-Pattern 5: Full Permissions In CI

In CI, combine --no-ask-user with minimal --allow-tool and explicit prompt boundaries. Avoid --allow-all unless the runner is sandboxed and the task is non-destructive.

Anti-Pattern 6: Static Model Tables

Model availability and pricing change. Document selection principles and link to GitHub’s model page instead of freezing a snapshot.

Conclusion

Copilot CLI is valuable because it connects terminal work, repository context, GitHub workflows, subagents, MCP/LSP, review, and automation into one supervised agent workflow.

The strongest practices are straightforward:

• encode project rules in instructions
• plan before hard changes
• keep permissions narrow
• improve context with LSP and MCP only when useful
• validate with tests and /review
• reserve Autopilot and /fleet for clear, bounded work

Used this way, Copilot CLI becomes more than a terminal chatbot. It becomes a coding agent you can safely fit into everyday engineering work.

References

• GitHub Copilot CLI
• Getting started with GitHub Copilot CLI
• Installing GitHub Copilot CLI
• Best practices for GitHub Copilot CLI
• GitHub Copilot CLI command reference
• Allowing and denying tool use
• Adding custom instructions for GitHub Copilot CLI
• Allowing GitHub Copilot CLI to work autonomously
• Running tasks in parallel with the /fleet command
• Adding MCP servers for GitHub Copilot CLI
• Using LSP servers with GitHub Copilot CLI
• Running GitHub Copilot CLI programmatically
• Automating tasks with Copilot CLI and GitHub Actions
• Supported AI models in GitHub Copilot
• Using your own LLM models in GitHub Copilot CLI
• About remote access to GitHub Copilot CLI sessions
• Managing pull requests with the /pr command
• GitHub Copilot CLI combines model families for a second opinion