Can a coding agent update an existing pull request?

Can my coding agent update an existing pull request instead of opening a new one

Yes. A coding agent can update an existing pull request when it makes changes on the same branch that the pull request already uses. GitHub treats a pull request as a review thread for a branch, so new commits on that branch extend the same pull request instead of creating a new one. GitHub’s pull request docs describe this workflow as responding to feedback and updating the pull request as it evolves.

The part people get wrong is branch identity. A pull request is tied to a head branch and a base branch. If the agent pushes to the same head branch, the open pull request updates. If it creates a new branch, GitHub opens a separate pull request because the branch range is different. GitHub’s docs also note that you can change the base branch of an open pull request, but that is a different action from updating the existing branch.

The practical rule is simple: use one branch for one review thread. Have the agent commit or push more changes to the branch that already backs the pull request, and the pull request stays in place. That fits GitHub’s basic pull request model, where a pull request proposes merging code changes from one branch into another.

This is the cleaner path when the review is still active. Review comments stay attached to the same pull request, the change history stays in one place, and reviewers do not have to switch between two nearly identical diffs. GitHub also supports updating the branch from the pull request page when the branch is behind the base branch, so the same pull request can keep moving forward as the code changes.

The inconvenient part is access. The agent must be able to push to that branch. If the branch lives in a fork, repository settings and permissions control whether maintainers can commit changes back to it. If the branch is protected or the update requires a rebase or merge from the base branch, the agent may need a human to approve or perform the branch update. GitHub documents that the Update branch button is not always available, especially for protected branches.

A good workflow is to let the agent work on a dedicated feature branch, open one pull request, and keep committing to that branch until the work is done. Example: the agent fixes a failing test, pushes the commit to the same branch, and the existing pull request shows the new commit right away. That is the normal GitHub flow, and it avoids reopening the same change as a second review.

When it goes wrong, the symptom is usually a duplicate pull request. That happens when the agent opens a new branch name for the next iteration, or when it writes to the wrong remote and GitHub cannot connect the commit to the original branch. The fix is to point the agent at the original head branch and push there again. If the branch is already merged or closed, then the next change belongs in a new branch and a new pull request.

If you are building this into a tool, the safest design is to store the branch name and pull request number together. The agent should update that same branch, not infer a fresh one from the task name. That keeps the review thread stable and makes the result predictable for the reviewer. DevConnect follows the same principle for agent work, keep changes on owned project assets and keep the review loop on one branch. https://devconnectplatform.com

What a coding agent should do

1. Check whether the pull request is still open.
2. Confirm the agent has push access to the head branch.
3. Commit the next change to that same branch.
4. Push the commit, then refresh the pull request.
5. Open a new pull request only if the branch is new, closed, or intentionally separate.

That sequence matches GitHub’s pull request model. Pull requests are for proposing changes from a branch, so the branch is the identity of the review. If the branch stays the same, the pull request stays the same too.

What reviewers see

Reviewers see the same pull request timeline, the same comments, and an updated commit list. GitHub’s docs say the conversation, commits, checks, and files changed views all live inside one pull request. That is why updating the existing branch is usually better than opening another PR for the same work.

When to open a new pull request instead

Open a new pull request when the new work belongs to a different branch, a different base branch, or a different review scope. GitHub also supports stacked pull requests, which are separate pull requests chained together when one change depends on another. In that case, each pull request stays distinct on purpose.

Bottom line

If the coding agent can push to the same branch, it should update the existing pull request. If it cannot, or if the work is meant to be separate, it should open a new one. The branch decides the pull request.