Use GitHub Copilot features

A developer on an organization's Copilot seat sees ghost text (the dimmed code suggestion at the cursor, also called an inline suggestion) in Visual Studio Code but no agent mode in Chat, while a colleague wonders whether to fix a failing test in the editor (IDE, integrated development environment) or hand it to Copilot cloud agent, which works on GitHub and returns a pull request: the first is a question of availability, the second a question of fit, and this domain, the most heavily weighted of the six at 25–30% (Use GitHub Copilot responsibly is 15–20%), keeps returning to both. Availability follows the access chain (this guide's name, not GitHub terminology): a Copilot client and a GitHub sign-in inside it (the editor's Copilot integration, or Copilot CLI after /login; for a feature on GitHub.com, such as Copilot code review, the chain starts at the plan), a Copilot plan that supplies the feature, and, when Copilot comes from an organization, a seat (the license an organization assigns to one user account) plus a policy that enables the feature on the surface in use, where a surface is one place and way Copilot is offered, such as ghost text in an editor, Copilot CLI in a terminal, or Copilot code review on a pull request (not every policy applies on every surface). Fit is judged by where the work runs (your editor, your terminal, or GitHub) and who drives the steps (you, accepting each change, or Copilot, working through a task you then review). The classic traps answer the right question the wrong way: reinstalling the integration to restore a feature that a policy turned off (the wrong link of the access chain), or picking the most autonomous option when the scenario is really asking who must approve each change (ignoring who drives the steps).

Use GitHub Copilot in the IDE covers completing the access chain in an editor, then choosing between the completion surfaces (ghost text and next edit suggestions, which predict the next related edit, both proposing code with no prompt) and the chat surfaces (ask mode and Inline Chat, which answer and propose, and agent mode, where Copilot chooses the files to change and the commands to run), plus content exclusion, the administrator control that keeps chosen files out of Copilot's context (in the editor, it is not currently supported in agent mode or in edit mode, the mode where you choose the files Copilot may change). Use GitHub Copilot CLI moves to the terminal, where Copilot CLI works as an agent (software that plans and carries out steps toward a goal) with your permissions: in an interactive session, in a one-prompt programmatic run, or handed to Copilot cloud agent with /delegate. Its interactive session offers default mode (or ask/execute mode), which, unlike ask mode in the editor, can edit files and run commands, asking your approval before potentially destructive actions; plan mode, which plans before writing code; and autopilot mode, which works through a task autonomously. Use GitHub Copilot Features and Capabilities sorts the capabilities that span surfaces into five jobs: change code, delegate work, extend and ground (give Copilot more tools and context; for example, MCP (Model Context Protocol) servers add tools and Copilot Spaces add curated context), review changes, and converse and reuse. Manage Organization-Wide Settings and Policies takes the organization owner's view: the policies and seat management that decide what developers on the other three pages can use, and the audit log that records who changed them. The table and decision tree below route a question to its page.

Across every page in this domain, Copilot's output is a proposal that someone with the right role accepts: a completion enters the file only when you accept it, agent mode's edits are there for you to review, a default Copilot code review leaves a Comment review (not an approval) that does not count toward required approvals (unless the separate Copilot approvals setting is enabled), and a pull request summary is a draft the author edits before posting. The same instinct favors the narrowest grant that gets the task done: in the terminal, that means the narrowest allow rule (a pre-approval for one tool, such as shell(git)) rather than allowing every tool, because approving a tool for the session approves every later use of it. An agent that iterates until its own checks pass has still only produced a proposal, so the answer that keeps human review in place is usually the one the scenario rewards.