Conversation
Adds GitHub Actions workflow that triggers claudius-review-action on `claudius-review` label or `/claudius:review` PR comment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new GitHub Actions workflow "Claudius PR Review" that triggers on Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub as GitHub Events
participant Runner as Actions Runner
participant Claudius as Claudius Action
participant ClaudeAPI as Claude API
GitHub->>Runner: pull_request_target (labeled/synchronize) or issue_comment(created)
Runner->>Runner: evaluate concurrency & permissions
Runner->>Runner: check conditions (label == "claudius-review" OR comment contains "/review" && author is OWNER/MEMBER/COLLAB)
alt Conditions met
Runner->>Claudius: invoke lklimek/claudius-review-action with inputs
Claudius->>ClaudeAPI: submit code + prompts (CLAUDE_CODE_OAUTH_TOKEN, model "opus")
ClaudeAPI-->>Claudius: review results
Claudius-->>Runner: post review (uses github_token to write PR/comments)
Runner-->>GitHub: create/update PR review/comments
else Conditions not met
Runner-->>GitHub: no-op
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can use Trivy to scan for security misconfigurations and secrets in Infrastructure as Code files.Add a .trivyignore file to your project to customize which findings Trivy reports. |
|
/claudius:review |
|
/claudius:review |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/claudius-review.yml:
- Around line 25-27: The issue: the issue_comment branch of the if in the
workflow allows any commenter to trigger /claudius:review; restrict it to
trusted commenters by adding an author association check. Update the existing if
expression (the multi-line conditional block) to require
github.event.comment.body contains '/claudius:review' AND that
github.event.comment.author_association is one of trusted values (e.g.,
'OWNER','MEMBER','COLLABORATOR','CONTRIBUTOR','MAINTAINER') using comparisons or
contains/startsWith logic with an array literal; use
github.event.comment.author_association in the condition so only those trusted
associations can trigger the workflow.
- Line 29: The workflow is using a mutable ref "uses:
lklimek/claudius-review-action@main" which is a supply-chain risk; replace the
"@main" ref with the action's immutable full commit SHA (e.g.,
"@<full-commit-sha>") for lklimek/claudius-review-action, updating the "uses"
line accordingly; fetch and verify the intended commit SHA from the action
repository (or vendor a known-good SHA) and use that exact 40-character commit
hash in the workflow so the action execution is pinned to a fixed commit.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 30db46a6-8178-435c-87fc-0f610371cf45
📒 Files selected for processing (1)
.github/workflows/claudius-review.yml
- Use claude_code_oauth_token instead of anthropic_api_key - Skip label/synchronize triggers on draft PRs - Comment trigger (/claudius:review) still works on drafts Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Only OWNER, MEMBER, and COLLABORATOR can trigger review via comment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds a new GitHub Actions workflow to run the “Claudius” automated PR review action when explicitly triggered via label or slash-command comment.
Changes:
- Introduces
.github/workflows/claudius-review.ymlworkflow for PR review automation - Triggers on
pull_request_target(label + synchronize) andissue_comment(/claudius:review) with concurrency control - Grants workflow permissions needed to post PR/issue comments and supplies required tokens/secrets to the action
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| on: | ||
| pull_request_target: | ||
| types: | ||
| - labeled | ||
| - synchronize | ||
| issue_comment: |
| (github.event_name == 'pull_request_target' && contains(github.event.pull_request.labels.*.name, 'claudius-review') && github.event.pull_request.draft == false) || | ||
| (github.event_name == 'issue_comment' && github.event.issue.pull_request && contains(github.event.comment.body, '/review') && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)) | ||
| steps: | ||
| - uses: lklimek/claudius-review-action@main |
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
This PR adds a CI workflow for AI-powered PR review using pull_request_target, which grants access to repository secrets even for fork PRs. The workflow has reasonable gating (label requirement, collaborator-only comment trigger, draft-PR filtering), but has one blocking security issue — the action is referenced by a mutable branch (@main) rather than a pinned commit SHA — and several logic/hardening suggestions.
Reviewed commit: e77497f
🔴 1 blocking | 🟡 3 suggestion(s) | 💬 1 nitpick(s)
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `.github/workflows/claudius-review.yml`:
- [BLOCKING] lines 31-34: Action pinned to mutable branch, not commit SHA
`lklimek/claudius-review-action@main` references a mutable branch. This action receives `CLAUDE_CODE_OAUTH_TOKEN` and `GITHUB_TOKEN` and runs in a `pull_request_target` context, which grants access to base-repo secrets even for fork PRs. If the upstream action repository is compromised or force-pushed, an attacker gains access to these credentials and can write to any PR in this repo.
GitHub's security hardening guide recommends pinning third-party actions to a full-length commit SHA. This is especially critical here because: (1) the action is from a personal account, not a verified org, (2) it runs in a `pull_request_target` context with elevated trust, and (3) it receives secrets. This repo already follows SHA-pinning in `milestone.yml` (`actions/github-script@f28e40c7...`), making `@main` an outlier.
- [SUGGESTION] lines 27-29: `labeled` trigger re-runs review when unrelated labels are added
The condition checks `contains(github.event.pull_request.labels.*.name, 'claudius-review')` for all `pull_request_target` events, without distinguishing between `labeled` and `synchronize` actions. When the `labeled` event fires, `github.event.pull_request.labels` contains *all* current labels on the PR, not just the newly added one. So if `claudius-review` was added earlier and someone later adds an unrelated label (e.g., `bug`), the `labeled` event fires, the condition is satisfied, and the review workflow runs again unnecessarily.
The fix is to check `github.event.label.name == 'claudius-review'` specifically for the `labeled` action, while keeping the `contains()` check for `synchronize` events.
- [SUGGESTION] lines 4-7: `synchronize` + `pull_request_target` + `cancel-in-progress` enables TOCTOU risk on labeled PRs
The `synchronize` trigger fires when new commits are pushed to a PR. Combined with `pull_request_target` and `cancel-in-progress: true`, this creates a potential time-of-check/time-of-use scenario: (1) a collaborator reviews code and adds the `claudius-review` label, (2) the review starts, (3) the contributor pushes new commits before the run finishes, (4) `cancel-in-progress` cancels the in-flight run and starts a new one with the label still present, (5) the new run reviews the updated (potentially malicious) code.
The practical risk depends on the action's internals — `pull_request_target` checks out the base branch by default, but the action may check out the PR head for review purposes. If the action does check out PR code, the attacker-controlled CLAUDE.md or `.claude/` files could influence Claude Code's behavior.
Consider removing `synchronize` from the triggers and requiring explicit re-labeling for each review cycle, or verifying that the action does not check out untrusted code.
- [SUGGESTION] line 29: Loose substring match on `/review` comment trigger
`contains(github.event.comment.body, '/review')` matches `/review` as a substring anywhere in the comment. Comments like "please don't /review this yet" or URLs containing `/review` will trigger the workflow. While the collaborator-association gate limits who can trigger it, unintentional triggers still waste CI resources and may post unwanted review comments.
Using `startsWith()` would provide a more precise match. Note that `startsWith` trims leading whitespace in some GitHub expression contexts, so `/review` on its own line at the start of a comment would still work.
| - uses: lklimek/claudius-review-action@main | ||
| with: | ||
| claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
🔴 Blocking: Action pinned to mutable branch, not commit SHA
lklimek/claudius-review-action@main references a mutable branch. This action receives CLAUDE_CODE_OAUTH_TOKEN and GITHUB_TOKEN and runs in a pull_request_target context, which grants access to base-repo secrets even for fork PRs. If the upstream action repository is compromised or force-pushed, an attacker gains access to these credentials and can write to any PR in this repo.
GitHub's security hardening guide recommends pinning third-party actions to a full-length commit SHA. This is especially critical here because: (1) the action is from a personal account, not a verified org, (2) it runs in a pull_request_target context with elevated trust, and (3) it receives secrets. This repo already follows SHA-pinning in milestone.yml (actions/github-script@f28e40c7...), making @main an outlier.
| - uses: lklimek/claudius-review-action@main | |
| with: | |
| claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} | |
| github_token: ${{ secrets.GITHUB_TOKEN }} | |
| - uses: lklimek/claudius-review-action@<full-40-char-commit-sha> # pin to audited commit |
source: ['claude', 'codex']
🤖 Fix this with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `.github/workflows/claudius-review.yml`:
- [BLOCKING] lines 31-34: Action pinned to mutable branch, not commit SHA
`lklimek/claudius-review-action@main` references a mutable branch. This action receives `CLAUDE_CODE_OAUTH_TOKEN` and `GITHUB_TOKEN` and runs in a `pull_request_target` context, which grants access to base-repo secrets even for fork PRs. If the upstream action repository is compromised or force-pushed, an attacker gains access to these credentials and can write to any PR in this repo.
GitHub's security hardening guide recommends pinning third-party actions to a full-length commit SHA. This is especially critical here because: (1) the action is from a personal account, not a verified org, (2) it runs in a `pull_request_target` context with elevated trust, and (3) it receives secrets. This repo already follows SHA-pinning in `milestone.yml` (`actions/github-script@f28e40c7...`), making `@main` an outlier.
| if: | | ||
| (github.event_name == 'pull_request_target' && contains(github.event.pull_request.labels.*.name, 'claudius-review') && github.event.pull_request.draft == false) || | ||
| (github.event_name == 'issue_comment' && github.event.issue.pull_request && contains(github.event.comment.body, '/review') && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)) |
There was a problem hiding this comment.
🟡 Suggestion: labeled trigger re-runs review when unrelated labels are added
The condition checks contains(github.event.pull_request.labels.*.name, 'claudius-review') for all pull_request_target events, without distinguishing between labeled and synchronize actions. When the labeled event fires, github.event.pull_request.labels contains all current labels on the PR, not just the newly added one. So if claudius-review was added earlier and someone later adds an unrelated label (e.g., bug), the labeled event fires, the condition is satisfied, and the review workflow runs again unnecessarily.
The fix is to check github.event.label.name == 'claudius-review' specifically for the labeled action, while keeping the contains() check for synchronize events.
| if: | | |
| (github.event_name == 'pull_request_target' && contains(github.event.pull_request.labels.*.name, 'claudius-review') && github.event.pull_request.draft == false) || | |
| (github.event_name == 'issue_comment' && github.event.issue.pull_request && contains(github.event.comment.body, '/review') && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)) | |
| if: | | |
| (github.event_name == 'pull_request_target' && github.event.pull_request.draft == false && ( | |
| (github.event.action == 'labeled' && github.event.label.name == 'claudius-review') || | |
| (github.event.action == 'synchronize' && contains(github.event.pull_request.labels.*.name, 'claudius-review')) | |
| )) || | |
| (github.event_name == 'issue_comment' && github.event.issue.pull_request && contains(github.event.comment.body, '/review') && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)) |
source: ['codex']
🤖 Fix this with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `.github/workflows/claudius-review.yml`:
- [SUGGESTION] lines 27-29: `labeled` trigger re-runs review when unrelated labels are added
The condition checks `contains(github.event.pull_request.labels.*.name, 'claudius-review')` for all `pull_request_target` events, without distinguishing between `labeled` and `synchronize` actions. When the `labeled` event fires, `github.event.pull_request.labels` contains *all* current labels on the PR, not just the newly added one. So if `claudius-review` was added earlier and someone later adds an unrelated label (e.g., `bug`), the `labeled` event fires, the condition is satisfied, and the review workflow runs again unnecessarily.
The fix is to check `github.event.label.name == 'claudius-review'` specifically for the `labeled` action, while keeping the `contains()` check for `synchronize` events.
Issue being fixed or feature implemented
Adds automated AI-powered PR review via Claudius, triggered by label or comment.
What was done?
Added
.github/workflows/claudius-review.ymlthat invokeslklimek/claudius-review-action@main.Triggers:
claudius-reviewlabel to a non-draft PR/reviewon any PR (including drafts)Configuration:
CLAUDE_CODE_OAUTH_TOKENsecret) for authenticationopusOWNER,MEMBER,COLLABORATOR)The composite action handles:
claudius-reviewlabel removal on successHow Has This Been Tested?
Workflow YAML validated with Python yaml parser. Will be tested on first triggered PR after merge.
Breaking Changes
None.
Checklist:
🤖 Co-authored by Claudius the Magnificent AI Agent
Summary by CodeRabbit