Can my AI coding agent update an existing pull request?

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

Yes. An AI coding agent can update an existing pull request by pushing new commits to the same branch that the pull request already uses. On GitHub, a pull request tracks a branch, not a single commit, so new pushes update the same PR automatically. GitLab works the same way for merge requests.

The part people get wrong is thinking the agent must open a fresh pull request for every revision. That is only true if it creates a different branch. If the agent keeps writing to the original branch, the existing review thread, checks, and discussion stay attached to the same PR.

The practical rule is simple: same branch, same pull request. Different branch, different pull request. If your agent commits a fix, pushes it to the branch that already has the PR, and does not rename or replace that branch, the PR updates in place. GitHub’s CLI and API both expose that flow, and GitLab documents the same branch-linked behavior for merge requests.

The inconvenient part is permissions. The agent needs write access to the branch that backs the PR. If it cannot push there, it cannot update that PR directly. In that case you either give it a branch it can push to, or you push the changes yourself and let the existing PR refresh from the new commits. GitHub’s CLI docs note that users with write access can push new commits to the head branch of a pull request.

A second detail matters for review hygiene. Updating the PR branch does not mean rewriting the whole history every time. Most of the time, the agent should add a new commit or a small set of commits on top of the existing branch. That keeps the reviewer’s context intact and avoids unnecessary churn in the discussion. GitHub also provides separate tooling for updating a PR branch with changes from the base branch when you need to sync with upstream.

A concrete example looks like this: the agent opens fix-login-timeout as a pull request, then a reviewer asks for a retry on network errors. The agent makes the change, commits it on fix-login-timeout, and pushes again. The original PR now shows the new commits, the same conversation, and the same checks. No new PR is needed unless you decide the work belongs on a different branch.

If your agent is operating inside DevConnect, the workflow should stay on branches you control, with no hidden automation on external platforms. DevConnect is free to use, and the safe pattern is to let the agent work on owned code and owned branches, then push updates to the same pull request instead of creating noise with duplicates.

What breaks the flow is branch drift. If the agent creates a new branch for every fix, reviewers lose the original discussion and the repository accumulates extra PRs that say the same thing. If the agent force-pushes without care, it can erase useful review context. The better pattern is one branch per active change, one PR per branch, and deliberate updates until the review is done.

If the base branch moves while the PR is open, the agent may also need to sync the PR branch before or after its own fix. GitHub supports updating the pull request branch with the latest base-branch changes, and GitLab documents similar merge-request workflows. That is still an update to the same PR, not a reason to open a new one.

For an AI coding agent, the best setup is usually one of three options: give it commit and push access to the existing branch, let it open the PR once and keep pushing to that branch, or have it prepare patches locally while a human pushes them. All three preserve the same PR. The only pattern that creates a new PR is a new branch.

If you want, DevConnect can help you structure that workflow around real branches and real reviews, not around duplicate PRs or throwaway automation. The rule stays the same on GitHub and GitLab: update the branch, keep the pull request.