Restore pull-requests: write for claude-review

[d-morrison]

Summary

• Revert claude-review to the pull_request trigger #89 fixed the claude-review job's OIDC token-exchange failure by reverting the trigger from pull_request_target back to pull_request, and in the same change narrowed permissions.pull-requests from write to read.
• That side effect silently breaks reviews on same-repo PRs: the job now runs to completion successfully (confirmed on PR #87, run 30681158599) but every attempt to actually post the review is denied — the job log shows "permission_denials_count": 8 and No buffered inline comments — so no review ever appears on the PR, even though the check shows green.
• Restoring pull-requests: write is safe: this workflow uses the pull_request trigger (not pull_request_target), and GitHub always forces a read-only GITHUB_TOKEN for PRs from forks regardless of what permissions: declares. So fork PRs stay read-only either way — this change only restores write access for same-repo PRs, which is the common case in this repo and where reviews were silently being dropped.

Test plan

• Confirm claude-review posts an actual review comment on a same-repo PR (e.g. re-run against PR Skip PR preview deploy for fork pull requests #87)
• Confirm a PR from a fork still only gets a read-only token (no change in behavior there)

---

Generated by Claude Code

[github-actions]

PR Preview Action v1.8.1-2-g6ad689f
Preview removed because the pull request was closed.
2026-08-01 04:04 UTC

[d-morrison]

Confirming this, with evidence that strengthens the case: the bug is older than #89, so this is not a regression I introduced --- it is a defect I restored while claiming it was safe.

claude has never posted a review comment on this repository:

PR	Date	pull-requests	claude comments
#78	2026-07-02	read	0
#79	2026-07-02	read	0
#80	2026-07-02	read	0
#86	2026-07-31	read	0

All four ran green. git log -L on the permissions line shows pull-requests: read was there from the workflow's first commit (0413ece), so every review this repo has ever run has been silently dropped at the posting step --- the failure mode you measured as permission_denials_count: 8.

My reasoning in #89 was wrong and is worth correcting explicitly. I wrote that restoring read was safe because "the action posts with its own app token, so the workflow token does not need write." The app token covers the action's own bookkeeping; the review itself is posted by Claude's tool calls, which run under GITHUB_TOKEN. I asserted that without testing it, and I also described the pre-#83 config as "the last version that produced successful reviews" --- it produced green checks and no reviews, which I would have caught by looking for a single claude comment on any earlier PR.

Worth noting for the record: Copilot reviewed #89 twice and repeated my premise back approvingly. Two clean reviews on a false claim, because both of us reasoned about which token ought to post rather than checking whether a review had ever appeared.

Your fork caveat is right --- GitHub forces a read-only GITHUB_TOKEN on fork PRs whatever permissions: declares, so this only affects same-repo PRs, and #90 stays open for the fork case.

One suggestion: this PR is the first chance to observe a genuine review on this repo. Its own claude-review run will still be under the old read permission (the head's workflow is what runs, and the fix is in that head --- so it should actually post). If a claude comment appears on this PR, that is the first one ever here, and worth saying so in the PR body.

[d-morrison]

One correction to the last point: this PR's own claude-review run did not get a genuine review, and the green check is misleading. The job log (run 30682869108) shows it was skipped outright by a GitHub-side guard:

##[warning]Skipping action due to workflow validation: Workflow validation failed.
The workflow file must exist and have identical content to the version on the
repository's default branch. ... your workflow will begin working once you
merge your PR.
Exiting due to workflow validation skip

Since this PR's diff is claude-code-review.yml itself, GitHub blocks claude-code-action from running with the modified permissions until the workflow file matches main — a sensible anti-privilege-escalation guard (a PR can't grant itself elevated permissions and exploit them in the same run). So the check is green because the job exited early, not because it reviewed anything and found nothing to say.

Practical effect: we won't get the first genuine confirmation from this PR. It'll come from the next PR opened/updated after this one merges to main.

---

Generated by Claude Code

[d-morrison]

Withdrawing the suggestion at the end of my last comment. This PR cannot be the demonstration --- I should have predicted that from the mechanism I had just finished writing up.

Because this PR edits the review workflow, its head no longer matches main, so its own run skips at workflow validation and exits 0 before reaching any posting step. Run 30682869108 confirms it:

Skipping action due to workflow validation: Workflow validation failed...
Exiting due to workflow validation skip

So the 0 claude comments on this PR carry no information about the permission fix, in either direction. Any workflow-editing PR is structurally incapable of testing its own change --- the same reason #89 could not verify itself.

The real test is the first same-repo PR pushed after this merges, with the workflow untouched: #76, #86, or #87. A claude review comment appearing on one of those is the confirmation, and it would be this repository's first.

Worth stating plainly, since the two failure modes now stack: a green claude-review on this repo currently means one of three things --- a real review posted, a review silently denied at posting (read permission, what this PR fixes), or a skip at workflow validation (any workflow-editing PR). Only reading the log distinguishes them, and only one of the three is a review.