Copilot Surfaces, CLI, and Cloud Agent
Most Copilot confusion comes from people comparing the wrong surfaces. This page separates the local, editor-first, terminal-first, and cloud-executed modes so you can pick the right one for the task instead of expecting one interface to behave like another.
1. The four main execution styles​
| Mode | Runs where | Best for | What to expect |
|---|---|---|---|
| IDE suggestions and chat | inside your editor | quick help, explanations, short edits | fastest feedback, least autonomy |
| IDE agent mode | your local development environment | multi-file fixes, local test loops | autonomous edits, still local |
| Copilot CLI | your terminal | shell-first coding and repo tasks | strong local control, scriptable |
| Copilot cloud agent | GitHub Actions-powered environment | async issue work, branch + PR generation | background execution on GitHub |
2. IDE chat and agent mode​
In the IDE, Copilot covers two different needs:
- chat and suggestions for immediate help while coding,
- agent mode for larger edit loops where Copilot can make changes, run checks, and iterate.
This is the most natural starting point for developers who already live in VS Code, JetBrains, Visual Studio, Neovim, or similar environments. It keeps the human in the loop and makes review friction low.
Use IDE agent mode when:
- the task is larger than a single completion,
- you want local feedback from your actual workspace,
- the repo is already checked out and ready,
- you still want tight supervision over each step.
3. Copilot CLI​
GitHub documents Copilot CLI as available across all Copilot plans, subject to organization policy when the seat is organization-managed. It gives you an agent in the terminal rather than in the editor.
What makes it useful:
- it supports interactive and programmatic use,
- it can work with repository files and shell commands,
- it supports custom instructions, custom agents, and MCP servers,
- it can run with local or cloud sandboxing,
- it can be used as an agent endpoint through ACP.
What makes it different from older "assistant in the shell" tools is that GitHub is clearly treating it as a real agent runtime, not just a command suggester.
When Copilot CLI is the best Copilot surface​
Choose Copilot CLI when:
- you think in commands, diffs, and test runs,
- you want to automate or script Copilot interactions,
- you need a local-first agent but do not want to leave the GitHub ecosystem,
- you want one bridge between terminal workflows and GitHub-native agent features.
Important safety habits for Copilot CLI​
GitHub's docs are explicit that Copilot CLI can read, modify, and execute on your behalf. In practice, that means:
- launch it from trusted project directories only,
- review approvals and shell actions carefully,
- prefer sandboxing for risky or experimental tasks,
- avoid running it from broad directories such as your home folder.
If your team wants a terminal agent but worries about blast radius, CLI sandboxing is one of the first things worth evaluating.
4. Copilot cloud agent​
Copilot cloud agent is the asynchronous side of the product. Instead of editing your local checkout, it works in an isolated environment on GitHub, can research a repository, make changes on a branch, and optionally open a pull request.
This is the right mental model:
- agent mode in the IDE = local autonomous pair programming,
- cloud agent = remote delegated engineering work.
Good use cases for cloud agent​
Cloud agent is especially useful for:
- backlog cleanup,
- repetitive maintenance tasks,
- issue-to-PR delegation,
- repository research and planning before implementation,
- opening a first draft that a developer can refine.
It is often more valuable as a parallel worker than as a replacement for active development.
Why cloud agent changes the workflow​
The GitHub-native advantage is not only code generation. It is workflow compression:
- branch creation is automatic,
- commits happen in the background,
- pull requests can be created for review,
- iteration can continue from issues, comments, or chat on GitHub.
That makes cloud agent a strong fit for teams that already organize work through issues and pull requests.
Cautions and constraints​
A few practical caveats matter:
- cloud agent availability depends on plan and admin policy,
- usage consumes both AI credits and GitHub Actions capacity,
- repository owners can opt repositories out,
- the environment is time-bounded and not a substitute for unlimited background compute.
Use cloud agent for bounded tasks with clear acceptance criteria, not for vague "fix the whole codebase" prompts.
5. A simple operating model​
For many teams, the best combined workflow looks like this:
- Explore and clarify in IDE chat or on GitHub.
- Use agent mode or Copilot CLI for local iteration.
- Use cloud agent for work that should continue asynchronously.
- Review every generated branch or PR like normal engineering output.
That keeps Copilot in the role of a productive collaborator, not an unreviewed source of change.