GitHub Copilot coding agent: a review of the pull request agent

GITHUB COPILOT CODING AGENT is an autonomous coding agent that lives on github.com. It takes a task as an issue or a chat prompt, works on it inside an ephemeral GitHub Actions environment, and opens a pull request with the result. The documentation now calls this surface the Copilot cloud agent, which is a better name: the pull request is the whole product. As a review, it is the most tightly integrated coding agent in existence, and that integration is both why it delivers work people actually merge and why it is hard to argue with on cost.

It is not an IDE feature and not a local agent. Nothing runs on a developer's machine: the agent gets its own runner, its own branch, its own firewall. That makes it the right shape for a queue — dependency bumps, test backfills, documentation sweeps, first-pass fixes for security alerts — and the wrong shape for the tight loop where someone wants to steer a single function signature. The [harness engineering trade-offs](/blog/harness-engineering-coding-agents) are the same model class with opposite ergonomics.

What it is

The surface is deliberately small. A task arrives as an assigned issue, from the agents panel, from Copilot Chat, from the REST API, from the GitHub CLI or from an MCP server. The agent clones one repository, plans, edits files, runs tests and linters, and pushes to a branch it created. That contract is enforced rather than requested: pushes are only allowed to branches beginning with copilot/, workflows triggered by its pull requests need approval from someone with write access, and it cannot reach other repositories in the same run.

• One repository per session. Cross-repository changes are impossible in a single run, so a codebase split across several repos needs a person in the middle.
• One branch and one pull request per task. Work that genuinely needs two pull requests means two tasks and two reviews.
• A hard ceiling of 59 minutes of execution per session, which the documentation states cannot be extended or bypassed.
• Commits are authored by Copilot with the requesting human as co-author, they are signed, and each commit message links to the session logs.
• CodeQL, secret scanning and dependency analysis run against the generated code during the session, and the agent attempts to resolve findings before pushing.
• No access to Actions secrets. Only secrets and variables explicitly added to the copilot environment are passed in.

How it works

Four server-side steps. The task is combined with repository context and sent to a GitHub-hosted model; the model plans and edits inside the ephemeral environment; tests and linters run there; the result is committed and pushed, and the pull request description becomes the session summary. After that the agent stays available: a review comment, or a mention of @copilot, is fed back in and produces another commit.

The session logs are the part teams under-use. Every commit links to them, they record which tools ran, and Copilot Chat on github.com can be asked what a pull request changed and why, because it pulls the logs into the conversation. When an agent-authored pull request looks wrong, the logs are often more informative than the diff: they show which test ran, which failed twice, and what the agent decided to do instead.

Where it breaks

The honest list is longer than the feature list. These are documented limits rather than bugs found in the wild, and they are the ones that decide whether a workflow survives a real backlog.

• The 59-minute ceiling is the one that hurts. Long migrations and multi-step refactors have to be cut into tasks that each fit, which turns one ticket into three tickets and three reviews.
• The agent only responds to users with repository write access. Comments from outside the repository never reach it, which cuts both ways: a sensible default, and a dead end for external contributors.
• Repository rules can block it outright. A rule that restricts commits to a fixed author list, for example, prevents it from opening or updating pull requests unless an administrator adds Copilot as a bypass actor.
• GitHub-hosted repositories only. A self-hosted GitLab, Gerrit or other code hosting platform gets nothing, and the documentation says so plainly.
• Not available on GitHub Enterprise Server. If that is the deployment target the answer is no, whatever the seat count.
• It can generate code matching public repositories even when the policy to block such suggestions is set. When that happens it shows a reference in the session log rather than a code reference on the suggestion.

Data handling differs by plan, and the difference matters during procurement. Prompts and suggestions sent from an IDE are not retained; prompts and suggestions from chat, mobile and CLI sessions are retained for 28 days. On Business and Enterprise they are not used to train models. On Free, Pro and Pro+ they may be, since 24 April, unless the account opts out. A team reading only the marketing page will not see that line, so check the plan before a rollout rather than after.

• A firewall is enabled by default on the ephemeral environment and blocks outbound connections to hosts that are not allowlisted. It can be customised or switched off, and widening it is the first thing to review when someone asks for it.
• Only the repository in the task is reachable. Other repositories in the same organisation are not.
• The agent filters hidden characters in issue bodies and comments, which closes the cheapest prompt-injection channel.
• Custom instructions, MCP servers and lifecycle hooks are configurable per repository or per organisation, so validation can run inside the agent loop rather than only in CI afterwards.

Getting started

The smallest useful integration is the agent tasks API: one POST, then a task id to poll. It is in public preview, it accepts only user-to-server tokens, and installation tokens are not supported — which rules out a GitHub App that triggers agent runs from a server-side webhook without a human token in the path.

# Start a task: only a user-to-server token works here
curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  -H "Authorization: Bearer $TOKEN" \
  https://api.github.com/agents/repos/octo-org/octo-repo/tasks \
  -d '{
    "prompt": "Fix the login button on the homepage",
    "base_ref": "main",
    "create_pull_request": true
  }'

# Poll until the state is completed, failed or timed_out
curl -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $TOKEN" \
  https://api.github.com/agents/repos/octo-org/octo-repo/tasks/$TASK_ID

The response carries a state field with queued, in_progress, completed, failed, idle, waiting_for_user, timed_out or cancelled, and that list is worth wiring into whatever calls it. waiting_for_user in particular is the one a naive poller gets wrong: the agent has stopped to ask a question, and nothing moves until a human answers on the pull request. The same work is available locally as gh agent-task create, gh agent-task list and gh agent-task view --log in GitHub CLI 2.80.0 and later, where the command set is itself a public preview.

Pricing and credits

Copilot is priced by seat, but agents burn a metered currency on top: GitHub AI credits, one credit worth 0.01 US dollars. Inline completions and next-edit suggestions do not use credits and stay unlimited on every paid plan; chat, agents, the CLI and Spaces do. The credit allowance, not the seat price, is what a team of agent-first developers actually manages.

Two pricing details decide whether this is affordable. First, agents are the expensive part of the credit economy: a long session on a frontier model across many files costs far more than a chat question, so a repository where every issue is auto-assigned will exhaust a Pro allowance within a week. Second, past the allowance there are three choices — wait for the reset, switch to a cheaper model, or enable paid usage with a dollar budget — and on Business and Enterprise the administrator, not the developer, makes that call. Since 1 June 2026 code review workflows also consume GitHub Actions minutes, so the runner bill moves with it.

Alternatives

The comparison that matters is not with other cloud agents, because there are very few. It is with the local-first coding agents that run in a developer's terminal. They share the model catalogue and the MCP story; they differ in where they execute and who owns the output.

The trade is not close on ergonomics. A local agent answers in seconds and can be interrupted mid-thought; this one returns a pull request in minutes and can only be steered by comment. What the local agents do not have is the pull request as the delivery format, branch protection, the scanning hooks and a session log a compliance team can read afterwards. Teams that already live in GitHub issues get more out of Copilot than teams that live in a terminal, and that is the only serious reason to pick it. More on the [tool-by-tool comparison](/blog/agents-md-skills-mcp-cli-decision-matrix) and the [sandboxing checklist](/blog/sandboxing-coding-agents-ci-checklist).

Verdict

Copilot cloud agent is worth the seat price for exactly one job: draining a well-written queue on github.com without a developer babysitting each session. It is a queue processor with a reviewer attached, not an autonomous colleague. Read it that way and it delivers; expect a pair programmer and it disappoints every time.

1. Use it for backlog items with objective acceptance criteria: dependency upgrades, generated tests, documentation, security alert fixes, first-pass refactors.
2. Do not use it for architecture, for changes that span repositories, or for anything the 59-minute ceiling would cut in half.
3. Keep branch protection, code owners and required reviewers. Its pull requests are drafts, which is a convention rather than an enforcement.
4. Budget on credits rather than seats, and set the paid-usage policy deliberately in both directions before the first overrun.
5. Budget review time. The bottleneck moves from writing the diff to reading it, which is a real saving and a real cost at the same time; the wider version of that argument is in [the AI-generated pull request review bottleneck](/blog/ai-generated-pr-review-bottleneck).

You should always review and test the content generated by the agent to ensure that it meets your requirements and is free of errors or security concerns prior to merging.

Sources

1. GitHub Docs: GitHub Copilot on GitHub.com, workflow and limitations
2. GitHub Docs: Application card, GitHub Copilot Agents
3. GitHub Docs: Plans for GitHub Copilot, prices and AI credits
4. GitHub Docs: Using Copilot cloud agent via the REST and GraphQL API
5. GitHub Docs: Using Copilot cloud agent from the GitHub CLI
6. GitHub Copilot product page: plans, privacy and FAQ
7. Anthropic: Claude Code product page
8. OpenAI: Codex CLI documentation