Pass --comment so claude-review actually posts its review - #97
Merged
Conversation
The code-review plugin gates all posting on a --comment argument: "If --comment argument was NOT provided, stop here. Do not post any GitHub comments." (step 7 of plugins/code-review/commands/code-review.md in anthropics/claude-code.) We have never passed it, so every review this repo has run has been working as designed -- reviewing, printing to the job log, and posting nothing behind a green check. claude has zero review comments across #78, #79, #80, #86, #87, #92, #93 and #94. This was not a permissions problem. #91's pull-requests: write and #92/#94's allowlist work were treating a symptom. Closes #96 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HMmB6db4xpbuqcqaQKArZb
Member
Author
|
Working on this --- paws off until I'm done. |
Contributor
|
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Claude Code Review GitHub Actions workflow so the code-review plugin is invoked with the --comment flag, enabling it to actually post review output back to GitHub (per the plugin’s documented behavior).
Changes:
- Add
--commentto thepromptpassed to/code-review:code-reviewso review findings are posted as GitHub comments instead of only appearing in job logs. - Add inline workflow comments documenting why
--commentis required (and referencing issue #96) to prevent regressions.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This was referenced Aug 24, 2026
d-morrison
added a commit
that referenced
this pull request
Aug 24, 2026
Fixes a blocking defect introduced by the previous round's own fix, and a factual claim I published in three places. - BLOCKING: the dispatch always passed `--ref "$PR_BRANCH"`, and a workflow_dispatch runs the workflow file as it exists at that ref. This PR is what ADDS the workflow_dispatch trigger, so every branch cut before it lacks it -- three of the four open same-repo PRs. Either the dispatch is rejected and `set -e` kills the step before the acknowledgment posts, or it runs a copy that selects no job and the acknowledgment posts anyway, reintroducing the false promise the fork short-circuit was added to prevent. Now tries the PR branch, falls back to a no-ref dispatch, and acknowledges only if one actually started a run -- reporting the failure on the PR otherwise. Removing upstream's REF_ARGS array last round had also removed the only no-ref path, which is what left a deleted head branch with no fallback. - FACTUAL: "it never executed once (5/5 runs skipped)" was wrong. That came from reading `--limit 5` and generalizing to the population. The real history is 25 runs: 23 skipped, one still in flight, and one success -- run 30687108541 on 2026-08-01, against fork PR #77, the exact case the workflow was written for. It executed and posted nothing because its prompt never carried `--comment` (#96), which #97 fixed for the other review workflow and never for this one. The justification for deleting it is that it was non-functional, not that it never ran. - FACTUAL: the user-facing fork notice blamed the OIDC exchange. That is the `pull_request`-path story (#90); a dispatched run executes in base-repo context with no fork token involved, and upstream describes its guard as failing a mistaken dispatch fast rather than closing a hole. - "produces no run at all" corrected -- a skipped run is still recorded. - `pull-requests: read` restated as declared rather than required, since a public repo would permit the read anyway. - The `pull-requests: write` rationale covered only the pull_request trigger; added what bounds the workflow_dispatch path. - Disambiguated "Set this to true", which sat five lines from its referent with `require-review` as the nearer antecedent, and split the three unrelated paragraphs sharing one heading. - report-cost's description corrected to "appends". Refs #101
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #96.
The actual cause
The
code-reviewplugin gates all posting on a--commentargument. From its own command definition,plugins/code-review/commands/code-review.mdstep 7:Our prompt has never passed it. So every review this repo has ever run has behaved exactly as designed: review the PR, print the findings to the job log, post nothing, exit 0.
claudehas zero review comments across #78, #79, #80, #86, #87, #92, #93, and #94.This was not a permissions problem
#91 (
pull-requests: write) and #92/#94 (allowlist) were all treating a symptom. I own a share of that: #89's permission change rested on an untested premise, and the two rounds of allowlist work that followed inherited the framing.The reasoning error is worth naming, because the evidence was sitting in plain text the whole time. Reviews on
Morrison-Lab/ai-configsay it verbatim in their own output:I read that sentence twice tonight while working other PRs and did not connect it to this symptom.
Why ai-config looks like it works
It consumes
d-morrison/gha's reusable review workflow, which has its own step that reads the last assistant message out of the execution output and posts it withgh issue comment. Its review comments are authored bygithub-actions[bot], notclaude--- that authorship is the tell.This repo calls
anthropics/claude-code-actiondirectly, so nothing wraps the output and the plugin's own posting path is the only one available. That path is gated on--comment.Verification, and its limit
The YAML parses and the prompt string ends with
--comment, confirmed by loading the file rather than eyeballing it.Beyond that, this PR cannot test itself: it edits
claude-code-review.yml, so its own run skips at workflow validation and exits 0 without reviewing anything. That is the same structural limit #89 and #91 hit.The real test is the first push to an open PR after this merges --- #76, #86, or #77. A
claude-authored comment there would be this repository's first.Still open, deliberately not bundled
permission_denials_countis 4, down from 8 (run 30686664862). Those four are unexplained and did not stop the review completing, so they are a separate question --- most likely the plugin's subagent launches, since its steps 1 through 5 each launch agents andTaskis not in the allowlist. Tracked in #96's closing section; worth ashow_full_outputrun once posting works, rather than changing two things at once.