GitHub Copilot CLI: AI-Powered Commands for DevOps Engineers

The terminal is still where most DevOps work actually happens. Linux administration, Git, Docker, Kubernetes, Terraform and OpenTofu, Ansible, cloud CLIs, curl, jq, ssh, systemd, networking tools, and gh all live at the command line — and remembering the exact flags for each is a constant tax. GitHub Copilot CLI puts an AI assistant right there in the shell, but with a discipline that matches how careful engineers already work: it proposes commands and waits for you to read and approve them before anything runs.

This is Part 3 of the GitHub AI Engineering Academy. Part 2, GitHub Copilot for DevOps Engineers, covered Copilot inside your editor. This lesson takes it to the command line. The core loop never changes:

Engineering Intent
       |
Natural Language
       |
   AI Assistance
       |
  Shell Command
       |
 Engineer Review   <-- required
       |
   Execution

Every command Copilot generates is reviewed before execution. The approval step is not a formality — it is the whole point.

What You’ll Learn

• What GitHub Copilot CLI is — the current standalone agentic copilot command, and how it differs from gh, Git, the shell, and VS Code Copilot.
• How to install and authenticate it — on Ubuntu/Linux primarily, with macOS and Windows notes.
• The approval-gated model — why Copilot CLI is an agent that asks before it runs anything, and how that is your review gate.
• Generating shell commands — real Linux examples for disk, memory, processes, ports, and logs.
• Git, Docker, Kubernetes, and Terraform workflows from the command line, each with risks and validation.
• GitHub CLI, curl, and jq examples for pull requests, runs, releases, and JSON APIs.
• Troubleshooting with Copilot CLI — a safe workflow for interpreting and remediating errors.
• Why you must never blindly execute AI-generated commands, plus 20 reusable prompts and a hands-on lab.

What Is GitHub Copilot CLI?

GitHub Copilot CLI is the current, standalone copilot command: an agentic assistant that runs in your terminal. You describe intent in natural language, and it can read files in the working directory, plan a series of steps, and propose shell commands to accomplish the task. It is powered by the same rotating set of frontier models as the rest of Copilot, so the exact model behind a response changes over time — there is no single model name to memorize.

Several similarly named things live near each other on the command line, and it helps to keep them distinct:

• The shell / terminal (Bash, Zsh) is the program that actually executes commands. Copilot proposes commands; the shell runs them.
• Git is the version-control tool (git commit, git rebase). It has nothing to do with AI.
• GitHub CLI (gh) is GitHub’s official command-line client for pull requests, issues, runs, and releases. It talks to GitHub.com.
• GitHub Copilot is the AI assistant. In the terminal it is the copilot program; in your editor it is inline suggestions and Copilot Chat.
• VS Code Copilot is that same AI assistant surfaced inside the editor — the subject of Part 4.

❗ Important — The old gh copilot suggest and gh copilot explain GitHub CLI extension is retired. Do not learn or use it. The current tool is the standalone agentic copilot command described here. GitHub’s AI tooling changes quickly, so verify exact commands against the official GitHub documentation before you rely on them.

The mental shift from the retired extension matters. The old model was “ask for a string, then copy-paste it yourself.” The modern copilot is an agent: it can plan and run commands directly — but only after you approve each one. That approval gate is what makes it safe to use, and it is the theme of this entire lesson.

Installing the Required Tools

Copilot CLI builds on the standard DevOps command-line stack, so install the foundations first.

Install Git and confirm it works:

sudo apt update
sudo apt install -y git
git --version

Install the GitHub CLI (gh) and check it:

sudo apt install -y gh
gh --version

gh is not strictly required to use Copilot CLI, but it is the tool you will pair with it most often, and GitHub CLI users can also launch Copilot via gh copilot.

Copilot CLI itself is Node-based. The documented install is a global npm package:

npm install -g @github/copilot

Then launch an interactive session simply by running:

copilot

On macOS the flow is the same after installing Node (for example brew install node, then npm install -g @github/copilot). On Windows, install Node.js from nodejs.org, then run the same npm install -g @github/copilot in PowerShell or Windows Terminal.

Verify the pieces are present:

node --version
copilot --version

❗ Important — Install commands for AI tooling change often. Treat npm install -g @github/copilot as the currently documented method, not a permanent guarantee. Confirm the exact install command and any prerequisites in the official GitHub documentation before setup.

Authentication

Copilot CLI authenticates from inside the session, not with a separate command. Start it:

copilot

On first run in a directory, it asks you to trust the folder — you can trust it for this session only, or remember the choice. This is a deliberate safety prompt: the agent will operate in that working directory, so it wants your explicit consent.

Once inside, log in with the slash command:

/login

Follow the on-screen flow (typically a browser-based device authorization). After it completes, you can confirm you are signed in by checking your usage or context:

/usage

Using Copilot CLI requires an active GitHub Copilot entitlement on your account. Plans and access levels change, so verify your plan’s Copilot access in GitHub’s documentation rather than assuming.

⚠️ Warning — Never paste secrets — API tokens, passwords, private keys, connection strings — into a Copilot prompt. Prompts may be processed and logged. For the same reason, avoid putting credentials directly on the command line where they land in your shell history; use environment variables or credential files instead, and reference them by name.

How the Copilot CLI Works (Approval-Gated)

This is the most important section in the lesson. Copilot CLI is an agent that can run commands, but it will not run anything that modifies or executes without asking you first.

When you describe a task, Copilot may need to use a tool — running find, editing a file with sed, calling kubectl, invoking terraform, and so on. Before any such action, it pauses and shows you the exact command, and you choose:

• Approve once — run this specific command a single time.
• Approve for the session — allow this kind of action for the rest of the session (use sparingly).
• Reject and redirect — decline, and tell Copilot what to do differently.

That prompt is the engineer review gate from the diagram at the top of this lesson. You read the proposed command, understand each part, and only then approve it. Pure read-only queries are low risk; anything that writes, deletes, or executes deserves a careful look every time.

For extra isolation, you can enable sandboxing within a session:

/sandbox enable

The real in-session slash commands you will use are limited and worth knowing:

Slash command	What it does
/login	Authenticate the session
/agent	Manage the agent configuration
/add-dir	Grant access to another directory
/cwd	Show or change the working directory
/resume	Resume a previous session
/usage	Show usage information
/context	Show the current context
/compact	Compact the conversation to save context
/sandbox enable	Turn on sandboxed execution
/settings	View or change settings
/feedback	Send feedback to GitHub

Stick to these verified commands; there is no benefit in guessing at others.

✅ Best Practice — Default to “approve once.” Reserve “approve for the session” for a batch of clearly read-only work you are actively supervising. The moment a proposed command writes, deletes, or executes, read it in full before approving — the approval gate only protects you if you actually use it.

Generating Shell Commands

For each request below, the loop is the same: you ask in plain English, Copilot proposes a command, you read and understand it, you approve it, and then you validate the output. The commands shown are the kind of correct, safe answers you should expect — and should verify.

1. Find the largest files under /var, excluding Docker’s data directory.

sudo find /var -type f -not -path '/var/lib/docker/*' \
  -printf '%s %p\n' 2>/dev/null | sort -nr | head -20

This searches /var for regular files, excludes anything under /var/lib/docker (whose layered storage would dominate and mislead), prints size in bytes and path, sorts largest-first, and shows the top 20. Risks are low because it only reads, but note sudo and confirm the exclusion path matches your Docker root. Validate by dividing %s by 1048576 for MB, or spot-checking a path with ls -lh.

2. List filesystems that are more than 85% full.

df -hP | awk 'NR>1 && int($5) > 85 {print $5, $6}'

df -hP prints usage in a stable, portable format; awk skips the header, parses the percentage column, and prints only filesystems above 85% with their mount points. Edge case: awk 'int($5)' strips the % sign correctly. Validate against the full df -h output.

3. Show the top memory-consuming processes.

ps -eo pid,ppid,user,rss,comm --sort=-rss | head -11

This lists processes sorted by resident memory (rss, in KB) descending, showing PID, parent, user, memory, and command. The head -11 keeps the header plus ten rows. To read rss in MB, divide by 1024. Cross-check with top or free -h for a live view.

4. List listening TCP ports and the processes bound to them.

sudo ss -ltnp

ss -ltnp shows listening (-l) TCP (-t) sockets with numeric ports (-n) and the owning process (-p, which needs sudo to see all processes). Validate by matching a PID back to a service with systemctl status or ps.

5. Find ERROR lines in the nginx log from the last hour.

journalctl -u nginx --since "1 hour ago" | grep -i error

If nginx logs to systemd, this pulls the last hour of its unit logs and filters for errors case-insensitively. If your nginx writes to files instead, the equivalent is grep -i error /var/log/nginx/error.log. Validate by widening the window (--since "2 hours ago") if you expected entries and saw none.

🛠️ DevOps Tip — When you ask for a shell command, add the constraints you care about: “portable, no GNU-only flags”, “read-only”, or “exclude /var/lib/docker”. A specific request produces a command you can approve with confidence instead of one you have to second-guess.

For more command-line depth, the Linux admin guides and the Bash and Python automation guides go well beyond single commands.

Git Workflows from the CLI

Copilot CLI is handy for the Git commands you use rarely enough to forget. Ask, read, approve, validate.

• Current branch: git branch --show-current.
• Commits that touched a file: git log --oneline -- path/to/file shows the history for just that path.
• Compare two branches: git log --oneline main..feature lists commits on feature not yet in main; git diff main..feature shows the content difference.
• Create a feature branch: git switch -c feature/new-thing creates and checks out a branch in one step.
• Undo a local commit safely: git reset --soft HEAD~1 removes the last commit but keeps your changes staged, so nothing is lost.
• Inspect a conflict: git diff --name-only --diff-filter=U lists files with unresolved merge conflicts.
• Find stale branches: git for-each-ref --sort=committerdate refs/heads/ --format='%(committerdate:short) %(refname:short)' sorts local branches by last commit date.
• Restore a file to the last commit: git restore path/to/file discards local changes to that file (which is itself destructive to uncommitted work — confirm first).

For rebasing, Copilot is more useful as an explainer than an executor. Ask it to explain what git rebase -i main will do to your branch’s history before you start, so you understand that it rewrites commits rather than merging them.

⚠️ Warning — Be extremely careful with git reset --hard. Unlike --soft, it discards your working-tree and staged changes with no undo. Have Copilot explain the exact consequences for your current state before you approve it, prefer --soft or git stash when you only want to move HEAD, and never run --hard when you have uncommitted work you might still want.

Docker CLI Examples

Copilot CLI is good at the Docker inspection commands that are easy to forget.

• Containers by memory usage: docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}' prints a one-shot snapshot of memory per running container.
• Images larger than 1GB: ask Copilot for a docker images command formatted with size, then sort — for example docker images --format '{{.Size}}\t{{.Repository}}:{{.Tag}}' and scan for GB.
• Why a container exited: docker inspect --format '{{.State.ExitCode}} {{.State.Error}}' <container> shows the exit code and any error, and docker logs <container> shows what it printed before dying.
• Tail and follow logs: docker logs -n 200 -f <container> shows the last 200 lines and then streams new output.
• Which network a container is on: docker inspect --format '{{json .NetworkSettings.Networks}}' <container> lists its attached networks.

Removing stopped containers is where care is needed. Copilot might propose:

docker container prune

This deletes all stopped containers, not just one. It is convenient but destructive, so Copilot will ask for approval — and you should confirm you do not need any of those stopped containers (for their filesystem state or logs) first. The same caution applies to docker image prune and especially docker system prune, which can remove images, networks, and build cache.

⚠️ Warning — Do not accept a blanket docker system prune -a just because it frees space. It removes all unused images and build cache across the host, which can turn a quick rebuild into a long one and delete images you meant to keep. Understand the exact scope before approving any prune.

The Docker guides and the hands-on Docker Academy cover container troubleshooting in more depth.

Kubernetes CLI Examples

Kubernetes rewards knowing the sequence of diagnostic commands, not just one. Copilot CLI can propose each step and explain what to look for.

Useful one-off queries:

• Pods not Running across all namespaces: kubectl get pods -A --field-selector=status.phase!=Running.
• Pods with the most restarts: kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount' (read the tail of the list).
• Events by creation time: kubectl get events -A --sort-by='.metadata.creationTimestamp'.
• Pod resource usage: kubectl top pods -A (requires the metrics server).
• Which Deployment owns a Pod: read the Pod’s ownerReferences — kubectl get pod <pod> -o jsonpath='{.metadata.ownerReferences[0].name}' gives the ReplicaSet, whose owner is the Deployment.

When a pod is in CrashLoopBackOff, the value is the diagnostic path, not a single command:

kubectl get pods
       |
kubectl describe pod <pod>
       |
kubectl logs <pod>
       |
kubectl logs <pod> --previous
       |
kubectl get events
       |
inspect probes / resources

describe surfaces events, image pulls, and probe failures; logs shows the current container; logs --previous shows the crashed instance’s output, which is usually where the real error is; events give cluster-level context; and reading the probes and resource limits catches the common causes (a failing readiness probe or an OOMKill from a too-low memory limit).

Rolling back a Deployment is kubectl rollout undo deployment/<name> — a real change to running workloads, so read what the previous revision was (kubectl rollout history deployment/<name>) and approve deliberately.

⚠️ Warning — Treat any kubectl delete proposal with suspicion. Deleting a pod is usually harmless (the controller recreates it), but deleting a Deployment, namespace, or PersistentVolumeClaim can destroy workloads or data. Read the resource type and name before approving, and never approve a delete you do not fully understand.

The Kubernetes and Helm guides go deeper on probes, resources, and rollouts.

Terraform and OpenTofu CLI Examples

Copilot CLI helps most with the safe, read-only side of Terraform and OpenTofu (tofu), and with explaining output.

• Format and validate: terraform fmt -recursive and terraform validate are safe and catch style and schema issues before a plan.
• Preview changes: terraform plan -out plan.tfplan records a plan you can review and apply exactly.
• Inspect state read-only: terraform state list and terraform state show <address> show what Terraform tracks without changing anything.
• Workspaces: terraform workspace list and terraform workspace show tell you which environment you are targeting — a critical thing to confirm before any apply.
• Interpret plan output: paste a confusing plan and ask Copilot to explain what is being created, changed, or destroyed, and why a change might force replacement.

The danger zone is state mutation. Commands like terraform apply, terraform destroy, terraform state rm, terraform import, and -target change real infrastructure or the state file that represents it.

⚠️ Warning — Never execute AI-generated state-manipulation or destructive Terraform against production without fully understanding it. terraform destroy tears down resources; terraform state rm silently orphans them; import and -target can leave state inconsistent; a careless apply can replace stateful resources. Confirm your workspace, read the plan line by line, run in a non-production environment first, and require explicit human approval before anything mutates state.

See the Terraform guides and, for the fork, the OpenTofu guides.

GitHub CLI Examples

Copilot CLI pairs naturally with gh for GitHub workflows. These are current, stable gh commands:

• List and view pull requests: gh pr list and gh pr view <number>.
• Create a pull request: gh pr create --fill opens a PR from your current branch.
• Create an issue: gh issue create --title "..." --body "...".
• List workflow runs: gh run list.
• Read a failed run’s logs: gh run view <run-id> --log-failed prints only the failed steps’ output — a fast way to find why CI broke.
• List releases: gh release list.
• Check auth: gh auth status confirms which account and scopes you are using.

These are read and create operations against your own repositories; they are low risk, but as always, confirm the repository and branch context before creating anything.

curl and jq Examples

A lot of DevOps work is calling an API and parsing the JSON. Copilot CLI is good at building curl and jq pipelines.

Call a REST endpoint and pretty-print the JSON:

curl -s "https://api.example.com/v1/jobs" | jq .

-s silences the progress meter; jq . formats the response.

Filter an array of objects to those with a failed status:

curl -s "https://api.example.com/v1/jobs" \
  | jq '.jobs[] | select(.status == "failed") | {id, name, status}'

This walks the jobs array, keeps only objects where status equals failed, and projects a small object with the fields you care about. jq also handles extracting nested fields (.data.items[0].id), collecting arrays ([.jobs[].id]), and counting (.jobs | length).

For endpoints that need authentication, use a placeholder and read the token from the environment — never a literal:

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.example.com/v1/jobs" | jq '.jobs | length'

To check a status code without the body, add -o /dev/null -w '%{http_code}\n', and to inspect response headers use curl -sI.

⚠️ Warning — Never expose real credentials in a curl command. Reference a variable like $TOKEN that you set in your environment, keep it out of shell history, and do not paste real tokens into a Copilot prompt. A token on the command line or in a screenshot is a leaked token.

Troubleshooting with Copilot CLI

Beyond generating commands, Copilot CLI is a strong troubleshooting partner for Linux, Docker, Kubernetes, and Terraform errors. It can interpret a cryptic systemd failure, a Docker build error, a kubectl describe event, or a Terraform provider error and suggest what to check next. Treat its explanations as hypotheses to confirm — it is reasoning from text, not from your live system.

Use this workflow to keep it safe:

Capture Error
      |
Remove Sensitive Info
      |
Ask AI to Explain
      |
Generate Diagnostics
      |
Engineer Verifies   <-- required
      |
Apply Remediation
      |
Validate

The two steps engineers most often skip are the second and the fifth. Redact secrets, tokens, hostnames, and personal data from any error you share. And after applying a fix, verify it actually worked — re-run the failing command, check the logs, or confirm the pod is Running — rather than assuming the suggested remediation was correct.

🔍 Troubleshooting — When you ask Copilot to diagnose, ask it to propose read-only diagnostic commands first (describe, logs, status, plan) before any remediation. Understanding the cause with safe commands is almost always better than jumping to a fix you have not justified.

Never Blindly Execute AI-Generated Commands

The approval gate only protects you if you use it well. AI-generated commands can be subtly or catastrophically wrong, and these are the patterns to watch for before you approve anything:

• rm -rf with a wrong or variable path, especially with sudo.
• Recursive permission or ownership changes like chmod -R or chown -R on the wrong directory.
• Formatting or partitioning commands (mkfs, dd, writing to /dev/).
• Package removal that pulls out dependencies you need.
• Deleting Docker, Kubernetes, or cloud resources — prune, delete, destroy at the wrong scope.
• terraform destroy or state manipulation against the wrong workspace.
• Shell expansion and globbing surprises, where * matches more than you expect.
• Piping the internet into a shell — curl ... | sh runs unknown code as you.
• Overwriting configs with > instead of appending with >>, or editing in place with sed -i.
• Credential exposure — secrets on the command line or in history.
• Command substitution — $(...) running a nested command you did not read.
• Dangerous sudo — elevating a command whose blast radius you have not checked.

When a proposed command is unfamiliar, inspect it before approving. command --help and man command tell you exactly what a flag does, and reading them takes seconds compared to recovering from a mistake that has no undo.

✅ Best Practice — Adopt one rule: never approve a command you cannot explain out loud. If you cannot say what each part does and why it is safe, reject it and ask Copilot to explain the command first. That single habit prevents almost every AI-assisted CLI accident.

20 Copilot CLI Prompts for DevOps Engineers

Reusable starting prompts. Each produces a proposed command to read, understand, and approve — never to run blind.

1. “Find the 20 largest files under /var, excluding /var/lib/docker.”
2. “Show filesystems that are more than 85% full.”
3. “List the top ten processes by memory usage.”
4. “Show listening TCP ports and the processes bound to them.”
5. “Find ERROR lines in the nginx logs from the last hour.”
6. “Which branch am I on, and what commits are on it but not on main?”
7. “Undo my last local commit but keep the changes staged.”
8. “Explain what git rebase -i main will do before I run it.”
9. “Show running containers sorted by memory usage.”
10. “Explain why this container exited and show its last 200 log lines.”
11. “Remove stopped containers, and tell me exactly what will be deleted first.”
12. “List pods that are not Running across all namespaces.”
13. “Diagnose this CrashLoopBackOff — propose read-only commands first.”
14. “Which Deployment owns this pod?”
15. “Roll back this Deployment, and show me the previous revision first.”
16. “Run terraform validate and explain any errors.”
17. “Explain what this terraform plan will create, change, or destroy.”
18. “Show the failed steps from my most recent GitHub Actions run.”
19. “Call this API with curl and list only the jobs whose status is failed.”
20. “Explain this shell command line by line before I run it.”

Lab: Troubleshoot a Failing Container Using AI-Assisted CLI Commands

A container named ai-api starts and then exits almost immediately. Use Copilot CLI to work through it, noting where AI helps and where your judgment is required.

1. Check status. Ask Copilot for a command to see the container’s state: docker ps -a --filter name=ai-api. You will see it in an Exited state.
2. Get the exit code. docker inspect --format '{{.State.ExitCode}} {{.State.Error}}' ai-api. A non-zero exit code tells you the process failed rather than finished cleanly.
3. Read the logs. docker logs ai-api (add -n 200 to bound it). This is where most container failures explain themselves — a missing env var, a bad config path, a port already in use.
4. Inspect the configuration. Have Copilot show the effective config: docker inspect ai-api and focus on Cmd, Entrypoint, and WorkingDir. Confirm the container is actually starting the command you expect.
5. Check environment variables without exposing secrets. Ask for the names only, not the values: docker inspect --format '{{range .Config.Env}}{{println (index (splitList "=" .) 0)}}{{end}}' ai-api. You are confirming a variable is present, not printing its secret value into your terminal.
6. Check mounts. docker inspect --format '{{json .Mounts}}' ai-api | jq . confirms whether an expected volume or config file is actually mounted.
7. Check networking. docker inspect --format '{{json .NetworkSettings.Networks}}' ai-api | jq . and verify the container is on the network it needs to reach its dependencies.
8. Identify the failure. Combine the log message with what you found in config, env, mounts, and networking. This synthesis is engineer judgment — Copilot can suggest likely causes, but you decide which one matches the evidence.
9. Fix it. Suppose the logs showed a missing DATABASE_URL. Ask Copilot for a corrected docker run command that sets it from your environment — not a literal secret. Read the proposed command before approving.
10. Restart. Run the corrected command (approve it deliberately), or docker start ai-api if only a dependency needed fixing.
11. Validate. docker ps --filter name=ai-api to confirm it stays up, and docker logs -f ai-api to confirm it is serving. Do not declare victory until you have watched it run.

Throughout, Copilot accelerates recall of exact inspect and jq syntax and offers hypotheses — but reading the logs, redacting secrets, judging root cause, and confirming the fix are yours.

What’s Next

You can now use Copilot CLI across the DevOps command line — Linux, Git, Docker, Kubernetes, Terraform, gh, curl, and jq — with the approval gate as the constant that keeps you in control. The next lesson, Part 4: GitHub Copilot with VS Code, brings the same assistant into the editor, where inline suggestions, Copilot Chat, and agent mode carry the identical review-before-you-run discipline. Later parts, including Part 5 (GitHub Copilot with Terraform, coming soon), go deeper on specific tools.

If you took a different route here, revisit Part 2: GitHub Copilot for DevOps Engineers, or return to the GitHub AI Engineering Academy home for the full path.