Why agentic assistance belongs in the shell

GitHub Copilot CLI has been in public preview since September 2025, and the team behind it has been shipping updates at a steady clip. The core premise is simple: developers spend much of their day outside the IDE. Tasks like sshing into servers, debugging inside containers, triaging issues, managing CI/CD pipelines, and writing deployment scripts rarely map neatly to a code editor's workflow.

The terminal is the one environment that spans all of these contexts. By putting Copilot there and connecting it to the broader GitHub ecosystem, the tool aims to cut down on time spent hunting through man pages and documentation, letting you get work done without switching tools.

From unfamiliar repo to resolved issue

A good way to see what Copilot CLI can do is to walk through the journey of a developer picking up an unfamiliar project. Say you're filling in for a teammate and need to fix a bug where a Submit Feedback button overlaps a form on the UI. You don't know the codebase, language, or framework.

You can start by asking the CLI to clone the repository for you:

Clone the feedback repo and set us up to run it

Copilot will pull up the repo's documentation, figure out the dependencies needed to run it, and get you set up quickly—even if you don't know what those dependencies are. Before running any command, it asks for your permission and explains what it's about to do.

Once the repo is running, you might hit the classic "port already in use" error. Instead of remembering the right lsof or kill syntax, you can hand that problem to Copilot:

What is using port 3000?

The tool can identify the process ID using the port. You can kill the process yourself, or let Copilot handle it while you move on to other work:

Find and kill the process on port 3000

With the server running, you can confirm the feedback button bug. Rather than digging through the codebase manually, ask Copilot to analyze the problem. Since Copilot can process images, you can upload the screenshot from the bug report and ask for suggestions:

Fix the big shown in @FIX-THIS.PNG

Copilot will review the code, find the likely cause, and propose a list of changes. You review them and decide whether to apply them automatically—all within the terminal.

Using custom agents for project-specific checks

Before pushing changes, teams often have strict requirements that a developer unfamiliar with the project might not fully know. In this example, the team has a custom agent that encodes its accessibility requirements, equipped with MCP tools for verifying those guardrails.

You can list available custom agents to find the right one:

/agent

Then invoke it to review your proposed changes:

Review our changes

The agent reviews the changes, and if it finds issues, it flags them and suggests fixes aligned with its instructions. This pattern is valuable when you have domain-specific agents that can act as automated gatekeepers for your code.

Finally, you might want to see if the work you've done resolves any open issues. Instead of manually searching through GitHub, Copilot CLI ships with the GitHub MCP server, giving you access to repository data directly from the terminal:

Are there any open issues that map to the work we're doing?

The MCP server searches across open issues and identifies ones matching your work. For issues that aren't fully resolved by your changes, you can delegate follow-up work to a coding agent:

/delegate Finish fixing the issue outlined in #1 and use the playright MCP server to ensure that it's fixed

The /delegate command dispatches a coding agent to handle the task in the background. It creates a pull request with the agent's work. This follows the standard Copilot coding agent workflow, just initiated from the CLI.

Headless operation for automation

Beyond interactive use, Copilot CLI supports headless operation. That same "kill process on port 3000" example becomes a one-liner:

copilot --allow-all-tools -p "Kill the process using port 3000"

Copilot determines and runs the appropriate commands to identify and kill the process. While this is a simple case, the pattern extends to more complex scenarios, like wiring the CLI into scripts or CI/CD workflows for repeated use.

The example above includes the --allow-all-tools flag, which you'll typically want to avoid in real environments unless you're inside a container. The CLI provides several flags to restrict access to certain directories and tools. You can even forbid Copilot from running specific commands, guaranteeing human involvement for sensitive operations like pushing to a repository.

To see the full list of supported flags:

copilot --help

Authentication for automations is supported via interactive login or a personal access token. More enterprise-friendly auth methods are in active development.

Installing and giving feedback

Copilot CLI is available for Windows (WSL and native PowerShell), macOS, and Linux, with platform-specific installation instructions provided in the Copilot CLI README.

The project is shipped from a public GitHub repository where open issues track requested features. That's where you can see planned work or submit your own feedback.