ci(review): explicit caller-job permissions on the Claude review caller - #1790
Conversation
Grant contents:read + pull-requests:write + id-token:write at the calling-job level (union of the reusable's per-job declarations), matching gemini-review.yml in this repo and oauth's claude caller. Without the block the grants come from the repo's default-workflow-permissions setting — GitHub silently intersects the reusable's requests with that ceiling, so pull-requests:write survives only while the repo default is "write". Surfaced by review feedback on rocksdb-js#701; pattern documented upstream in ai-review-prompts#74. Addresses the claude-review.yml entry in #568. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
kriszyp
left a comment
There was a problem hiding this comment.
Least-privilege caller-job permissions are correct — the granted scopes are exactly the union the reusable workflow's jobs request, matching the existing gemini-review.yml block. Both red checks are explained non-regressions (anti-tamper guard that clears on merge + an unrelated uWS flake). Approving.
🤖 Reviewed with KrAIs (Claude Opus 4.8)
Ethan-Arrowood
left a comment
There was a problem hiding this comment.
LGTM — explicit, minimal caller-job permissions, matching the established pattern. The red review / review check is the anti-tamper guard behaving as designed, not a real failure. Approving. (Sibling of harper-pro#580, same change.)
sent with Claude Opus 4.8
v5.1's caller workflow was stuck at the pre-#1790/#1891 version — no explicit id-token/pull-requests permissions block and an older ai-review-prompts pin. GitHub's OIDC->app-token exchange for the review job requires the invoking workflow file to be byte-identical to the one on the repository's default branch (main), so every PR based on v5.1 was failing "review / review" with a 401 workflow validation error, unrelated to the PR's actual diff. Co-Authored-By: Claude Opus <noreply@anthropic.com>
v5.1's caller workflow was stuck at the pre-#1790/#1891 version — no explicit id-token/pull-requests permissions block and an older ai-review-prompts pin. GitHub's OIDC->app-token exchange for the review job requires the invoking workflow file to be byte-identical to the one on the repository's default branch (main), so every PR based on v5.1 was failing "review / review" with a 401 workflow validation error, unrelated to the PR's actual diff. Co-Authored-By: Claude Opus <noreply@anthropic.com>
One block: grant
contents: read+pull-requests: write+id-token: writeon thereviewcalling job inclaude-review.yml— the union of what the reusable'sauthorizeandreviewjobs declare, matchinggemini-review.ymlin this repo (which has carried the block since it was added post ai-review-prompts#39/#40) and oauth's claude caller.Why
Without an explicit block the caller inherits the repo's default-workflow-permissions setting: GitHub silently intersects the reusable's per-job requests with that ceiling (verified on a live run — granted set was exactly
Contents: read, PullRequests: write, with the requestedid-token: writedropped). Reviews work today only because the repo default is "write"; flipping that setting to "read" would break review posting with unhelpful 403s. Explicit job-level grants remove the hidden dependency.Cross-references
claude-review.ymlentry in Audit and tighten GITHUB_TOKEN permissions on CI workflows #568 (the AI-review slice of that audit;claude-mention.yml/claude-issue-to-pr.ymlremain)with:block) — whichever merges second is a trivial rebaseNote: this PR edits the caller workflow, so its own Claude review check fails with the expected anti-tamper guard; clears on merge.
🤖 Generated with Claude Code