ci: skip claude.yml when comment is '@claude review'#1737
ci: skip claude.yml when comment is '@claude review'#1737felixweinberger merged 1 commit intomainfrom
Conversation
Comments starting with '@claude review' are handled by the hosted code-review webhook, which creates a dedicated check run. Running this workflow on the same trigger causes both systems to respond to one comment — the GHA run then fails on fork PRs because it tries to fetch the fork branch from origin.
|
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
There was a problem hiding this comment.
LGTM — straightforward CI condition to avoid double-triggering on @claude review comments.
Extended reasoning...
Overview
This PR modifies a single line in .github/workflows/claude.yml, adding a !startsWith guard to the issue_comment condition. This prevents the GitHub Action from firing when a separate hosted webhook already handles @claude review comments.
Security risks
None. This is a CI workflow condition change that only narrows when the workflow triggers. It does not alter permissions, secrets handling, or any runtime behavior.
Level of scrutiny
Minimal scrutiny needed. This is a one-line, mechanical change to a CI condition with clear motivation (preventing a double-trigger that causes spurious red checks on fork PRs). The logic is straightforward and easy to verify by inspection.
Other factors
No bugs were found. No outstanding reviewer comments. No changeset is needed since this is a CI-only change with no version impact. The PR description clearly explains the observed problem and the scoping decision (only issue_comment is excluded, not other event types).
Excludes
@claude reviewcomments from triggering this workflow.Motivation and Context
Comments starting with
@claude revieware handled by the hosted code-review webhook, which creates a dedicated "Claude Code Review" check run. When this GitHub Action also fires on the same comment, both systems respond — the GHA run then fails on fork PRs because it tries to fetch the fork branch from origin, leaving a red ❌ on the PR alongside the actual (successful) review.How Has This Been Tested?
Observed the double-trigger on PR #1003:
@claude reviewfired both the hosted webhook (check run started correctly) and this workflow (failed withgit fetch origin <fork-branch>).Breaking Changes
None.
Types of changes
Checklist
Additional context
Only the
issue_commentevent is excluded since that's the only event type the hosted webhook listens to.@claude reviewin a PR review comment or issue body still triggers this workflow as before.