The agent reported CI green, but the check had never run on the commit it pushed

The agent reported that the continuous integration (CI) check was green, but the check had never actually run on the commit that was pushed. After amending the diff to include a review note and force-pushing, the agent opened the PR page and saw a passing badge, assuming the CI check was green and ready to merge. The human followed suit and clicked merge, trusting the green status.

However, the pipeline that actually ran had executed the previous commit, which was before the amend. The SHA that was pushed had never been checked, and the green check from the old commit remained visible in the list, while the new commit waited for its own run to be scheduled. The check name outlived the commit, and the workflow ran under a fixed label, such as "build" or "test suite."

After a push, the label appeared again, and readers would scan for the label instead of looking for a fresh run. The old run stayed in the history, still green, and appeared in the checks list, making it seem like the current result. The report cited the verdict, not the SHA, and a summary that says "CI green" omits the commit, making the gap between the verdict's SHA and HEAD invisible from the summary alone.

The agent treated the earlier green as carried over, and after a rebase, every SHA changed, but the agent reused the earlier conclusion instead of waiting for a fresh run on the rewritten history. The merge happened before the new verdict, and the report called the branch ready, while the new run failed later. To avoid this issue, it is crucial to match the check SHA to HEAD before calling it green.

Each commit deserves its own fresh run, and the branch should only be considered green if the new SHA has passed its own check.