Skip to content

v0.8.0 — The reviewer is never asked about CI it cannot read

Choose a tag to compare

@raphaelcm raphaelcm released this 10 Aug 06:19
· 2 commits to main since this release
ed6b76e

The review agent stops being asked about CI

Every review used to carry a **CI status**: line, and every review filled it with a confession: "could not read". The agent's gh runs on the Claude App's own installation token (claude-code-action mints it via OIDC and ignores the step's GH_TOKEN), and that token cannot read the Checks or Actions APIs — the job-level checks: read + actions: read grants never reached it. Independently and decisively, the review runs on pull_request concurrently with CI and finishes minutes before CI does, so even a perfect token would have read pending. The model then escalated PRs citing its own blindness as the risk.

CI truth was never the reviewer's to report. The deterministic gate re-reads the CI conclusion on every wake and refuses anything but success regardless of the verdict, and that is where the composition of "verdict says merge AND tests pass" belongs. The CI investigation step, the comment-template line, the CI clauses in the decision criteria, and the CI-reading tools in the allow-list are deleted. Nothing replaces them: an allow-listed tool is an instruction to use it, so the deletion is the fix.

The autofix agent can finally read the failure it exists to fix

The fixer job fires only when CI fails, and its first step is gh run view --log-failed — which 403'd on the same App token, every time. The fixer step now passes github_token: ${{ secrets.GITHUB_TOKEN }}, so the job's checks:/actions: read grants actually reach the agent doing the reading. Its comments post as github-actions[bot], which is safe there: they carry no decision block and nothing wakes on them.

The identity contract is now written down and enforced

The review step must never take that same input. A comment created with GITHUB_TOKEN fires no workflow triggers (GitHub's recursion guard), so the gate's issue_comment wake-up only works because the review comment comes from the claude[bot] App identity. Pass the token there and any review that finishes after CI strands its PR until the next push. The workflow header now states this, and permissions.test.mjs enforces both sides: an agent without the passthrough may not allow-list any command whose scope the App token lacks, an agent with it must have every needed scope granted, the review step must not carry the input, and the autofix step must.

Also

  • The diagnose step goes red and labels the PR when the agent was denied gh pr diff: a review that never read the diff still posts an escalate-shaped decision block, and it used to stay green.
  • The pinned anthropics/claude-code-action moves to v1.0.187, so a re-render no longer rolls an adopter back to v1.0.183.