The GitHub Copilot Coding Agent: How It Takes a Task From an Issue

The GitHub Copilot coding agent is the version of Copilot that works on its own, on GitHub, instead of beside you in the editor. You assign it an issue or give it a prompt; it starts a session in a temporary environment run on GitHub Actions, reads the repository, changes code on a branch of its own, runs your tests and linters, and opens a pull request for you to review. You hand it a task and get back a diff, with every step in a commit and a log.

It now has a different name. GitHub’s changelog describes “Copilot cloud agent (formerly known as Copilot coding agent)” in its April 2026 announcement↗ (opens in a new tab), which also let it research and plan on a branch before any pull request exists. Older guides, and some of GitHub’s own page addresses, still say coding agent. They mean the same thing, and so does this post.

From issue to pull request, step by step

1. You write the issue. GitHub’s best practices for Copilot tasks↗ (opens in a new tab) ask you to treat the issue as a prompt: a clear description of the problem, complete acceptance criteria, and directions about which files need to change.
2. You assign it to Copilot, from the Assignees menu on the issue, from the repository’s issue list, or from the issue inside GitHub Projects. A dialog lets you pick the repository and base branch, add an optional prompt, and choose a custom agent or a model.
3. Copilot receives the issue title, the description, the comments that exist at that moment and your extra prompt. Comments added to the issue afterwards do not reach it, according to Using Copilot cloud agent on GitHub↗ (opens in a new tab). New information goes on the pull request instead.
4. It works in its own environment: it explores the code, makes changes, runs tests and linters, and pushes commits to a new branch whose name starts with copilot/.
5. It opens a pull request and requests your review when it has finished, which sends you a notification.
6. You review it like any other pull request. To ask for changes, mention @copilot in a comment and it pushes more commits to the same branch. If you have several comments, submit them together with Start a review, so it works on the whole review at once rather than on each comment separately.
7. A person merges it. Copilot cannot.

Other ways to start it

An issue is the classic starting point, but not the only one. The same agent can be started from:

• The Agents tab of a repository, or the agents panel at the top of any GitHub page: pick the repository, type a prompt, and ask for a pull request in the prompt if you want one straight away.
• Copilot Chat on GitHub.com, with /task. The session carries the context of the conversation, so you do not repeat yourself.
• A comment mentioning @copilot on any pull request, including ones people opened.
• The Fix with Copilot button on a failed GitHub Actions job, or on a pull request with merge conflicts.
• Automations that run it on a schedule or when an event happens, such as a new issue being opened.
• Your editor, the GitHub CLI and GitHub Mobile, which can start and track sessions without opening the website.

Whichever door you use, it helps to give the agent a working environment. It can install your dependencies by trial and error, which is slow; a copilot-setup-steps.yml file installs them before it starts, so its first minutes go on the task rather than on the build.

The guard rails around it

An agent that can push code is a risk, and GitHub’s page on risks and mitigations↗ (opens in a new tab) lists what it does about that. The ones that shape your day:

• Only people with write access to the repository can set it to work. Comments from anyone else never reach it.
• It pushes to one branch: its own new copilot/ branch, or the branch of the pull request where you mentioned it. Branch protections and required checks still apply.
• It cannot mark its pull request ready for review, approve it or merge it, and the person who asked for the pull request cannot approve it either, so your required-approvals rule still means another pair of eyes.
• By default your GitHub Actions workflows do not run on its pushes until someone with write access clicks Approve and run workflows. Look at any change under .github/workflows/ before you click.
• Its commits are authored by Copilot with the person who assigned the task as co-author, and each commit message links to the session log.

Limits to plan around

• One repository per task. It can change only the repository named when the task started, never several in one run.
• One branch and exactly one pull request per task.
• A session stops after 59 minutes, a hard limit stated in About GitHub Copilot cloud agent↗ (opens in a new tab). Work that needs longer should be split into smaller issues.
• It works only on repositories hosted on GitHub.
• A ruleset that allows only named commit authors can block it; with rulesets you can add Copilot as a bypass actor.

The limits favour small, well-described issues: a bug with a reproduction, a missing test, a documentation fix, a contained refactor. GitHub itself suggests keeping production incidents, security-sensitive changes and ambiguous work for people.

It is not agent mode

Agent mode is Copilot inside your editor: it edits files on your machine while you watch and approve each step. The coding agent runs on GitHub while you do something else, and you meet its work as a pull request. Different habits suit each one; GitHub Copilot agent mode best practices covers the editor side.

Tracking the work on a board

The issue and its pull request record one change well. They do not show the plan the change belongs to, the work that spans several repositories, or the tasks that are not code at all. If that plan lives on a board shared by people and AI assistants, the useful move is to connect the two with a reference, not to copy one into the other.

Start with the issue text. Because Copilot reads the issue once, when it is assigned, put the board reference in the description: “Board task: BUG-031”. Then give the agent a way to read that task and report back on it.

Copilot’s cloud agent takes MCP servers from the repository’s settings, under Copilot, MCP servers. The MCP configuration docs↗ (opens in a new tab) say it does not yet support remote servers that sign in with OAuth, so it needs a token sent as a header. In fenbs, issue one under Settings, “Connect an AI assistant”: name it after the agent, tick only read and comment, set an expiry if you want one, and copy it when it appears. Store it in the repository as an Agents secret whose name starts with COPILOT_MCP_.

{
  "mcpServers": {
    "fenbs": {
      "type": "http",
      "url": "https://fenbs.ai/api/mcp",
      "headers": {
        "Authorization": "Bearer $COPILOT_MCP_FENBS_TOKEN"
      },
      "tools": ["fenbs_whoami", "fenbs_get_context", "fenbs_get_item", "fenbs_search", "fenbs_comment"]
    }
  }
}

The tools list matters. The cloud agent uses a configured server’s tools without asking you first, and GitHub recommends allowing specific read-only tools. The list above reads the board and comments; it cannot move or delete anything. The token’s scopes are a second ceiling, and both sit under your own role on the board, so the agent can never do more than you could.

Then add two lines to the repository’s instructions file: “If the issue names a board task, call fenbs_get_item for it before you start. When you open the pull request, comment on that task with the link and what you changed.” Does GitHub Copilot read AGENTS.md? explains which file the cloud agent reads.

Leave the move to Completed to a person, after the merge. The lane then means “merged and checked”, not “an agent thinks it is done”. Every comment the agent leaves is recorded in the board’s history under the token’s name and yours, and revoking the token in Settings stops it at once without touching your own sign-in.