GitHub lets @copilot edit existing pull requests from the comment thread

GitHub announced on March 24, 2026 that developers can now mention @copilot directly in a pull request to ask Copilot coding agent to make changes on that existing PR. The new workflow is designed to keep follow-up implementation inside the review thread instead of forcing developers to leave the pull request and start a separate task flow.

GitHub’s examples cover three common use cases: fixing failing GitHub Actions workflows, addressing code review comments, and making additional code changes requested during review. Example prompts in the announcement include @copilot Fix the failing tests, @copilot Address this comment, and @copilot Add a unit test covering the case when the model argument is missing.

How the updated flow works

According to GitHub, Copilot coding agent runs in its own cloud-based development environment where it can make code changes, validate the result with the repository’s tests and linter, and then push the update back to the pull request. That means the agent is operating on the real branch context rather than proposing a detached patch with no validation step.

The company also notes a behavior change from the previous system. Before this update, asking Copilot to modify an existing pull request would cause it to open a new pull request on top of the original branch. If users still want that older stacked-PR behavior, GitHub says they can request it explicitly in natural language, for example by asking Copilot to open a PR to fix failing tests.

• Works by mentioning @copilot in the pull request conversation
• Supports test fixes, review feedback, and other follow-up code changes
• Copilot coding agent validates changes with tests and linting before pushing
• Pull requests from forks are not currently supported

GitHub says the feature is available with all paid Copilot plans, while Copilot Business and Copilot Enterprise users still need an administrator to enable Copilot coding agent. The update is significant because it moves more of the edit-review-iterate loop into the pull request itself, which is where teams already discuss, approve, and ship changes.