GitHub Copilot cloud agent takes a bounded repository task, works on a branch in GitHub’s cloud environment and gives you a diff or pull request to review. The cleanest workflow starts with a well-scoped issue or a direct prompt, then keeps the human review step explicit.

Docs checked: GitHub Copilot documentation as of October 21, 2026. Availability depends on your Copilot plan, account policies and repository settings.

On this page

Assign an issue when the task should become a pull request

Assigning an issue to Copilot is the direct path when the work is already defined and should end in a pull request. GitHub says issue assignment always creates a pull request and requests your review when the agent finishes.

Open the issue, choose Assignees, select Copilot, then set the target repository and starting branch. The optional prompt is where you add constraints that do not belong in the issue itself: required tests, files that must not change, a framework convention or a specific validation command.

At assignment time, Copilot receives the issue title, description and existing comments. It does not pick up comments added to the issue later. Put new requirements on the pull request after the session starts. GitHub documents the full flow in Assigning an issue to Copilot.

Treat the issue as the task prompt. A useful issue says:

  • what must change;
  • what must stay unchanged;
  • how to reproduce the current behaviour;
  • what result will count as complete;
  • which build, lint and test commands must pass.

Start from the Agents panel when you want a branch first

A direct prompt gives you a more gradual path. Open the Agents tab in a repository or the agents page, choose the repository and enter the task. You can select a base branch, a custom agent and, when available, a model and reasoning level.

By default, Copilot works on a branch. You can inspect the diff, send follow-up prompts and create a pull request when the branch is ready. If the initial prompt explicitly asks for a pull request, the agent can open one as part of the task. GitHub’s task-start guide distinguishes this branch-first flow from issue assignment, which always creates a pull request.

That difference is useful:

  • use an issue assignment for a defined backlog item that should enter review;
  • use a direct prompt for research, planning or an implementation you want to inspect before opening a pull request.

Keep each task inside the cloud agent’s limits

Copilot cloud agent works in an ephemeral GitHub Actions-powered environment. It can explore the selected repository, edit files, run commands, tests and linters, and push its changes. It is not an open-ended worker.

GitHub documents three hard boundaries: one repository, one branch and one pull request per task. A session can run for no more than 59 minutes. A repository ruleset can also block the agent if it prevents the agent from creating commits or updating a pull request.

Split work before assigning it if the task needs several repositories, a large architectural change or a long test suite. GitHub’s best-practices guide recommends starting with simpler work such as focused bug fixes, UI adjustments, test coverage, documentation, accessibility improvements and technical debt. It advises keeping complex, sensitive or ambiguous work with a person.

Put build and test instructions in the repository

A good prompt describes the immediate task. Repository instructions carry the durable operating rules.

GitHub says Copilot cloud agent can read these instruction files:

  • .github/copilot-instructions.md for repository-wide guidance;
  • .github/instructions/**/*.instructions.md for path-specific guidance;
  • AGENTS.md, CLAUDE.md and GEMINI.md files where applicable.

Put real commands and boundaries in them: how to install dependencies, which formatter to run, the test command, generated files that should not be edited, and conventions the pull request must follow. Avoid vague rules such as “follow best practices” when the repository can name the actual check.

Aftergradient’s Copilot custom instructions guide explains the file locations and scopes. For task-specific roles and tool sets, see GitHub Copilot custom agents.

Review the session log before the pull request

The session log shows what the agent did and which tools it used. GitHub notes that logs help reviewers follow the work, but they do not replace code review or testing.

Check the resulting branch or pull request in this order:

  1. Confirm the diff matches the task and did not widen the scope.
  2. Read changes to dependency files, workflows and configuration separately.
  3. Run the repository’s documented checks in a trusted environment.
  4. Review generated code for incorrect assumptions and security problems.
  5. Look at any public-code match references GitHub attaches to the session.
  6. Request a smaller correction instead of accepting a broad rewrite.

Copilot can generate incorrect or insecure code. GitHub’s Copilot on GitHub.com overview explicitly requires review and testing before production use.

Iterate on the pull request, not the old issue

After a pull request exists, continue the conversation there. A user with write access can mention @copilot in a pull request comment and describe the correction. Copilot pushes follow-up commits to the pull request branch by default.

If you have several review comments, GitHub recommends batching them into one review. That gives the agent the full set of changes at once instead of starting separate work for each comment. You can also push your own commits to the branch or ask Copilot to resolve merge conflicts.

The same boundary still applies: inspect every follow-up commit. A green agent session is not a substitute for the repository’s own CI, a human review or a security review.

A practical handoff checklist

Before you delegate:

  • choose one repository and one focused outcome;
  • make acceptance criteria observable;
  • name the starting branch;
  • include exact build and test commands;
  • point to repository instructions rather than copying them into every prompt;
  • keep credentials and private production data out of the task;
  • decide whether you want a branch first or an immediate pull request.

Before you merge:

  • read the session log and the complete diff;
  • run the required checks;
  • verify dependencies, workflows and permissions;
  • resolve review comments in one coherent batch;
  • keep the final merge decision with a repository maintainer.