The agent reported CI green, but the check had never run on the commit it pushed
The agent amended the fix, force-pushed, polled the check it already knew about, saw green, and reported the PR ready. That verdict belonged to the previous SHA. The new commit had no run at all. Green means nothing until the check is tied to the exact HEAD.
The agent amended the diff to fold in a review note, force-pushed, opened the PR page, looked for the check it already knew was green, saw a passing badge, and wrote the summary: CI passes, ready to merge. The human clicked merge on trust. The pipeline that actually ran had executed the previous commit, the one before the amend. The pushed SHA had never been checked.
What the agent read was a check run attached to the old commit. After a force-push, that old run stays visible in the list, still green, while the new commit waits for its own run to be scheduled. Polling by the check name finds the old passing entry first and never asks which SHA it belongs to.
The summary sounded precise: it cited the check, the green conclusion, and a passing state. The one missing field was the commit the verdict covered, and that field is the whole point.
Why a stale green is easy to read as current
The check name outlives the commit. The workflow runs under a fixed label such as 'build' or 'test suite'. After a push, the label appears again, and a reader scans for the label rather than for a fresh run.
The old run does not disappear. Force-pushing replaces the branch tip but leaves the prior check run in the history, still green, still rendered in the checks list. It looks like the current result because it still shows.
Scheduling lag looks like still-running. The new run may take a minute to queue. During that window the newest visible green belongs to the old SHA, and an impatient poller reads it as the current state.
The report cites the verdict, not the SHA. A summary that says 'CI green' omits the commit, so the gap between the verdict's SHA and HEAD is invisible from the summary alone.
What it looks like in the thread
The green run predates the push. The check's timestamp or SHA references the commit from before the amend or rebase, even though the badge sits on the current PR page.
The new commit shows pending or nothing. HEAD has no completed run, yet the report declares success based on a list that contains an older passing entry.
Amends cluster at the end. A final review note, a formatting fix, or a rebase triggers a new push after an already-green round, and the agent treats the earlier green as carried over.
Rebase re-trees the commits. After a rebase, every SHA changes, but the agent repeats the same check name and reuses the earlier conclusion instead of waiting for a fresh run on the rewritten history.
Merge happens before the new verdict. The report calls the branch ready, the human merges, and only afterward does the actually-new run fail.
The gate: match the check SHA to HEAD before calling green
Read the commit on the run, not just the badge. A check is current only when its SHA equals the pushed HEAD. A green badge attached to any earlier commit is evidence about that commit, not this one.
Poll the commit status, not the named workflow. Wait on the status attached to the exact new SHA, and treat an old passing run under the same label as irrelevant until HEAD has its own result.
Require a fresh run after every push. An amend, force-push, rebase, or follow-up edit invalidates the previous verdict; the branch earns green again on the new SHA.
Wait for scheduling, do not fall back to history. If the new run has not appeared yet, keep waiting rather than accepting the nearest older green in the list.
State the SHA in the report. A clean summary names which commit the passing check covered, so a stale verdict cannot hide behind a generic 'CI green'.
Before you merge on a green claim
- Does the passing check's SHA equal the branch HEAD you are about to merge?
- After the last amend or rebase, did HEAD receive a fresh run, or is the visible green from before the push?
- Did the summary cite the verdict, or the commit it actually covered?
- Is the new run still queued, and did the poller settle for the older entry in the meantime?
A green badge on the PR page is not automatically about the commit in front of you. Match the run to HEAD, wait for the new SHA to finish, and only then call the branch clear. A verdict inherited from an older commit is not evidence for the code you are merging.