Copilot coding agent (now Copilot cloud agent): how it works

GitHub Copilot coding agent is now called Copilot cloud agent. It is an agent that works on GitHub, not on your machine: you assign it an issue, mention @copilot on a pull request or start a task from the Agents tab, and it researches the repo, edits code and runs tests in an ephemeral environment powered by GitHub Actions, then pushes to a copilot/ branch for you to review.

GitHub's docs define it as "an AI-powered software development agent that can work autonomously on issues or developer requests." This guide uses the current name and is based on GitHub's Copilot cloud agent documentation read on 24 October 2026.

Why was Copilot coding agent renamed?

GitHub's April 2026 changelog put it this way: "Copilot cloud agent (formerly known as Copilot coding agent) is no longer limited to pull-request workflows." Today the agent can answer questions about a repository, propose a plan, iterate on a branch and only then open a pull request. Older articles and videos that say "coding agent" describe the same feature.

Who can use Copilot cloud agent?

GitHub's plans page shows:

For Pro, Pro+ and Max it is on by default. For Business and Enterprise, GitHub says it "is disabled by default and must be enabled by an administrator." Repository owners and admins can also opt individual repositories out. It only works with repositories hosted on GitHub.

How do you start a Copilot cloud agent task?

GitHub lists many entry points. The main ones on GitHub.com:

• Assign an issue. Open the issue, click Assignees, choose Copilot, and fill in the dialog: an optional prompt, target repository, base branch, custom agent and model. Copilot gets the issue title, description and existing comments. It does not see comments added after assignment, so put new details in a pull request comment instead.
• Agents tab or panel. Go to github.com/copilot/agents, pick a repository, type a prompt (screenshots and mockups are accepted) and optionally a base branch and model.
• Copilot Chat. Type /task followed by what you want. The session inherits the context of your chat.
• Pull request comments. Mention @copilot on any pull request, including ones you wrote, to ask for changes. It pushes to that pull request's branch by default.
• Failing Actions runs and merge conflicts. Ask Copilot to investigate a failing workflow run, or click Fix with Copilot in the merge box to resolve conflicts.
• New repositories. Enter a prompt when creating a repo and Copilot opens a draft pull request that seeds it.

Outside GitHub.com, you can start sessions from GitHub Mobile, VS Code, JetBrains IDEs, Eclipse, Visual Studio 2026, the REST API, the GitHub MCP server, Raycast, Slack, Microsoft Teams, Jira, Azure Boards and Linear. From the terminal, the GitHub CLI has a public preview command set (v2.80.0 or later):

gh agent-task create "Add input validation to the signup form" --follow
gh agent-task list
gh agent-task view --repo monalisa/bookstore 123 --log

In Copilot CLI, /delegate sends the current task to the cloud agent.

What happens while it works?

Copilot handles branch creation, commits and pushes. You can follow along in the session logs, send follow-up prompts to steer it, and ask Copilot Chat what changed and why. GitHub's research, plan and iterate guide notes that sessions started from the Agents tab "do not create pull requests automatically"; ask for one in your prompt, or click Create pull request when you are happy with the diff. Issue assignments and /task do open a pull request and request your review at the end.

Before finishing, the agent checks its own code by default with CodeQL, secret scanning, a GitHub Advisory Database check on new dependencies and a second opinion from Copilot code review. You can switch individual checks off in its settings.

How do you set up the agent's environment?

The agent can install dependencies by trial and error, but GitHub calls that slow and unreliable. The fix is a workflow file at .github/workflows/copilot-setup-steps.yml with a single job named copilot-setup-steps:

name: "Copilot Setup Steps"
on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml
jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Checkout code
        uses: actions/checkout@v6
      - name: Set up Node.js
        uses: actions/setup-node@v7
        with:
          node-version: "20"
          cache: "npm"
      - name: Install JavaScript dependencies
        run: npm ci

Things to know from the environment docs:

• Only steps, permissions, runs-on, services, snapshot and timeout-minutes (max 59) are honored; other settings are ignored.
• The file only takes effect once it is on your default branch.
• If a step fails, Copilot skips the remaining steps and starts with whatever is installed.
• runs-on can point at larger runners, self-hosted runners or a Windows environment instead of the default Ubuntu.

Secrets and variables for the agent are configured separately, and the agent's internet access goes through a firewall you can customize.

How do you guide its work?

The agent reads repository custom instructions, so .github/copilot-instructions.md and path-specific .instructions.md files apply. GitHub also lists AGENTS.md, CLAUDE.md and GEMINI.md as agent instructions for the cloud agent; see the custom instructions guide and the AGENTS.md guide.

For specialist work, add custom agents in .github/agents and Agent Skills in .github/skills, .claude/skills or .agents/skills. MCP servers extend what it can reach; by default the GitHub MCP server only sees the repository it is working in. Model choice is available when assigning issues, in @copilot pull request comments, and from the Agents tab or panel, GitHub Mobile and Raycast; elsewhere it uses Auto.

What are the limits?

From GitHub's docs:

• One repository per task. It cannot change several repositories in one run.
• One branch and one pull request per task.
• 59 minutes per session, a limit that "cannot be extended or bypassed."
• Write access required. Only people with write access can trigger it, and comments from others are never shown to the agent.
• Rulesets can block it. A rule that only allows specific commit authors, for example, can stop it; admins can add Copilot as a bypass actor.

How does GitHub keep it safe?

GitHub's risks and mitigations page lists these protections:

• It can only push to its own copilot/ branch, or the pull request branch when you mention it there, and cannot run git push directly.
• Its draft pull requests need human review. It cannot approve or merge, and the person who requested the work cannot approve it.
• GitHub Actions workflows do not run on its pull requests until someone with write access clicks Approve and run workflows, unless you change that setting.
• Internet access is restricted by a firewall.
• Hidden characters, such as HTML comments in issues, are filtered out to reduce prompt injection.
• Commits are signed, authored by Copilot with the requester as co-author, and link to the session logs.

How does it compare with similar agents?

Cursor's Cloud Agents take the same approach in a different product: a cloud VM, its own branch and a pull request at the end. If you want an agent inside your existing Actions workflows instead, see Claude Code GitHub Actions.

Reuse what works

Good task prompts and skills make the cloud agent far more reliable, and they are worth keeping. Kipt stores your prompts and Agent Skills as Markdown in a private GitHub repo you own, with tags and Cmd+K search, so a prompt that produced a clean pull request is easy to find for the next issue.