The review-data JSON that claude-code-review.yml posts can carry a
commit_sha that is not a commit on the PR branch.
Observed
On Morrison-Lab/ai-config#3414,
the review posted at 2026-09-09T08:46 UTC ended with:
Reviewed commit: 277da5f6497729035a7d629bab46018129395b8f
while its structured block read:
"commit_sha": "3f1b1d6b8a8ea7b60bd05ae91a79de4bd6ade43a"
277da5f6 is the PR head. 3f1b1d6b is GitHub's ephemeral merge commit,
confirmed via the commits API:
Merge 277da5f6497729035a7d629bab46018129395b8f into 96a90414668ca16a9f6dee62b4dfc64cb2726104
committer: web-flow
That commit exists on no branch and disappears when the PR closes, so the
field points at nothing durable. The likely cause is the reviewer reading
GITHUB_SHA, which on a pull_request event is the merge ref rather than
github.event.pull_request.head.sha.
Impact today: none, and the reason is worth stating
Morrison-Lab/ai-config's scripts/check-pr-fully-clean.py builds
is_sha_match as a disjunction of the structured commit_sha, the 7-character
head prefix in the body, and the full head SHA in the body. The trailing
Reviewed commit: line supplies the real head, so the body-scan disjunct
matches and the freshness test still passes.
So this is latent rather than live. It bites a consumer that reads
commit_sha alone, which is the field's natural reading and the one a
structured block invites -- and it fails in the safe-looking direction, since
such a consumer concludes the review is stale rather than that the data is
wrong.
Suggested fix
Resolve the reviewed commit from github.event.pull_request.head.sha (with
the dispatch-path stash head as the fallback, matching what post-review
already stale-checks against) and use that for both the structured field and
the trailing line, so the two cannot disagree.
A test asserting the two agree would be worth more than the fix alone: they
are produced in different places, which is how they came to differ.
Not blocking
No check is red over this and no verdict is affected.
Posted by Claude Code (AI agent) --- not written by a human.
The
review-dataJSON thatclaude-code-review.ymlposts can carry acommit_shathat is not a commit on the PR branch.Observed
On Morrison-Lab/ai-config#3414,
the review posted at 2026-09-09T08:46 UTC ended with:
while its structured block read:
277da5f6is the PR head.3f1b1d6bis GitHub's ephemeral merge commit,confirmed via the commits API:
That commit exists on no branch and disappears when the PR closes, so the
field points at nothing durable. The likely cause is the reviewer reading
GITHUB_SHA, which on apull_requestevent is the merge ref rather thangithub.event.pull_request.head.sha.Impact today: none, and the reason is worth stating
Morrison-Lab/ai-config'sscripts/check-pr-fully-clean.pybuildsis_sha_matchas a disjunction of the structuredcommit_sha, the 7-characterhead prefix in the body, and the full head SHA in the body. The trailing
Reviewed commit:line supplies the real head, so the body-scan disjunctmatches and the freshness test still passes.
So this is latent rather than live. It bites a consumer that reads
commit_shaalone, which is the field's natural reading and the one astructured block invites -- and it fails in the safe-looking direction, since
such a consumer concludes the review is stale rather than that the data is
wrong.
Suggested fix
Resolve the reviewed commit from
github.event.pull_request.head.sha(withthe dispatch-path stash head as the fallback, matching what
post-reviewalready stale-checks against) and use that for both the structured field and
the trailing line, so the two cannot disagree.
A test asserting the two agree would be worth more than the fix alone: they
are produced in different places, which is how they came to differ.
Not blocking
No check is red over this and no verdict is affected.
Posted by Claude Code (AI agent) --- not written by a human.