What an AI Agent Must Recheck Before Merging a Pull Request

Consider a hypothetical sequence. A reviewer approves a pull request at commit A. Before anything merges, the contributor pushes commit B, which changes code. No reviewer has looked at B. An automated merge step now holds an approval for A and a branch whose head is B. If it merges the current head, it merges an unreviewed change. If it tries to merge A specifically, the branch no longer matches.

This is a possible sequence, not a claim about its prevalence. Its value is that it separates three questions that are easy to blur: which commit was reviewed, whether that review still applies, and whether the change has been tested in the state it will actually enter the repository. A SHA is the identifier of a commit. The head is the current tip of the pull request branch. Each of the three questions maps to a different check.

The reviewed commit is an identity question

An approval records judgment about a version of the work. If the version changes, the identifier is the first thing to verify.

GitHub's synchronous merge a pull request endpoint accepts a sha parameter specifying the head commit the caller expects. When the supplied SHA differs from the current head, the endpoint responds with HTTP 409. That is a narrow guarantee: the commit selected for merging is the commit the caller identified. It says nothing about whether tests passed, whether the review was adequate, or what the target branch contains. Identity of the reviewed input is the only thing it pins.

This is why, in the hypothetical above, an attempted synchronous merge supplying A would meet a head mismatch once B exists. The mismatch is the system doing its job: the reviewed object and the merge candidate are no longer the same object.

A commit match is only meaningful when the expected identifier is tied to the review record. Workforce's technical overview documents a review-pr, prepare-pr, merge-pr sequence in which the merge step verifies that the reviewed commit is the commit selected for merging. That is the identity check placed inside a chained workflow: review produces a record, and the merge step refuses to act on a different commit.

Review freshness is a policy question

Identity alone does not answer whether the review still applies after the branch moves. That is configurable repository policy.

GitHub's protected branch settings offer two distinct controls here. One dismisses stale approvals when changes affect the reviewed diff; with it enabled, a changed diff needs approval again. The other requires approval of the most recent reviewable push by an authorized reviewer other than the person who pushed it. These are not the same rule, and neither is universal. Which one applies is a decision the repository makes, and an agent acting in that repository has to know the answer before it treats an existing approval as sufficient.

Required status checks sit alongside these review rules as a separate control. A matching head SHA is not evidence that tests passed, and a green test run is not evidence that anyone reviewed the diff. Each control answers its own question.

In the hypothetical, once B changes code and no reviewer has looked at B, merging would include an unreviewed change. What must happen next depends on the configured rule: B is reviewed again, or B gets a fresh approval from someone other than its pusher.

Integration state is a third question

Even a reviewed head with a fresh approval has only been tested in the state the checks actually ran against. A pass is evidence about the configured checks on that state, not proof of general correctness.

GitHub's merge queue exists because the target branch moves too. A queue validates each pull request combined with the latest target branch and the pull requests ahead of it, using temporary branches, before merging. The tested object in a queue is therefore not the reviewed head alone; it is a combination that includes other changes. That is deliberately different evidence, and it should be described as such.

The queue path has one operational prerequisite worth stating precisely. When GitHub Actions supplies required checks for a merge queue, the workflows need the merge_group trigger in addition to pull_request. Without it, the required queue checks are not reported and the merge fails. A repository that requires a queue must be exercised through the queue; the synchronous endpoint is not a way around it.

A bounded evaluation in a disposable repository

I recommend testing each check separately, in a repository created for the purpose, rather than testing one blended merge and guessing which rule fired.

First, exercise the configured stale-review rule. Get an approval, then push a code-changing commit and observe whether the approval is dismissed or whether last-push approval is now required. This tells you which freshness policy the repository actually enforces.

Second, isolate the synchronous API head precondition in a repository without a required merge queue. Review the current head B, satisfy the other merge prerequisites, then submit the stale expected SHA A. The documented result is a head mismatch. Keep the other prerequisites satisfied, because the documentation does not establish which error wins when several things fail at once.

Third, test a queue-enabled repository through its queue path, with fresh approvals and workflows that carry the merge_group trigger. Do not send the direct merge experiment through a required queue; that conflates two different mechanisms.

None of this is presented as already tested or deployed. It is a procedure for learning which controls your repository enforces before an agent depends on them.

Keep the evidence distinct

Reviewed commit, review freshness, and tested integration state are three separate answers to three separate questions. A head match proves identity. A freshness policy proves the review still applies. A queue validation proves something about a combined state that includes other work. None of the three substitutes for another, and passing all three is not a complete authorization model. It is necessary evidence, gathered inside permissions and repository rules that people define. The discipline is to refuse to let one check quietly stand in for the others.