Debug GitHub Actions skipping on Claude tag

[piatoss3612]

Add repository check to allow PRs from the same repository to trigger the Claude workflow, even if author_association is CONTRIBUTOR. This handles private organization members who appear as CONTRIBUTOR instead of MEMBER.

External contributors (from forks) are still blocked for security.

[github-actions]

Code Review

I found 2 critical issues in this PR:

Issue 1: Incorrect context object for issue_comment events (Line 19)

For issue_comment events, github.event.pull_request does not exist in the event payload. This object is only available for pull_request, pull_request_review, and pull_request_review_comment events.

When a user comments on a PR issue, the issue_comment event provides:

• github.event.issue - the issue/PR object (limited fields)
• github.event.comment - the comment object
• github.event.issue.pull_request - a minimal object with URLs (if the issue is a PR)

But github.event.pull_request.head.repo.full_name will always be undefined/null for issue_comment events, making this repository check non-functional.

Reference: GitHub issue_comment event payload documentation

Affected code:

keplr-example/.github/workflows/claude.yml

Lines 18 to 19 in c3154bd

	(github.event.comment.author_association == 'OWNER' || github.event.comment.author_association == 'MEMBER' || github.event.comment.author_association == 'COLLABORATOR' ||
	(github.event.issue.pull_request && github.event.pull_request.head.repo.full_name == github.repository))) ||

Fix needed:

Fix .github/workflows/claude.yml:19: For issue_comment events, github.event.pull_request does not exist. You need to either use a different approach or fetch PR details via API to get the head repo information.

Issue 2: Security vulnerability - Authorization bypass (Lines 19, 22, 25)

The repository check github.event.pull_request.head.repo.full_name == github.repository is added as an OR condition, which allows ANY GitHub user to trigger the Claude workflow by commenting on PRs from non-fork branches, regardless of their author_association.

Attack scenario:

1. A repository member creates a PR from a branch in the main repo
2. Any GitHub user (even with no permissions) comments @claude on that PR
3. The workflow triggers because the PR's head repo matches the target repo
4. The author_association security gate is completely bypassed

The check verifies where the PR came from but not who is commenting. This conflates two orthogonal security concerns.

Affected code:

• keplr-example/.github/workflows/claude.yml

  Lines 17 to 19 in c3154bd

  	(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude') &&
  	(github.event.comment.author_association == 'OWNER' || github.event.comment.author_association == 'MEMBER' || github.event.comment.author_association == 'COLLABORATOR' ||
  	(github.event.issue.pull_request && github.event.pull_request.head.repo.full_name == github.repository))) ||

• keplr-example/.github/workflows/claude.yml

  Lines 20 to 22 in c3154bd

  	(github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude') &&
  	(github.event.comment.author_association == 'OWNER' || github.event.comment.author_association == 'MEMBER' || github.event.comment.author_association == 'COLLABORATOR' ||
  	github.event.pull_request.head.repo.full_name == github.repository)) ||

• keplr-example/.github/workflows/claude.yml

  Lines 23 to 25 in c3154bd

  	(github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude') &&
  	(github.event.review.author_association == 'OWNER' || github.event.review.author_association == 'MEMBER' || github.event.review.author_association == 'COLLABORATOR' ||
  	github.event.pull_request.head.repo.full_name == github.repository)) ||

Suggested fix: Use AND logic to require CONTRIBUTOR association on non-fork PRs:

(github.event.comment.author_association == 'OWNER' || 
 github.event.comment.author_association == 'MEMBER' || 
 github.event.comment.author_association == 'COLLABORATOR' ||
 (github.event.comment.author_association == 'CONTRIBUTOR' && 
  github.event.pull_request.head.repo.full_name == github.repository))

This would allow CONTRIBUTORs (org members appearing as such) to trigger on non-fork PRs while still requiring some level of association.

---

Action required: Please address both issues before merging. The security vulnerability is particularly critical as it could allow unauthorized users to execute Claude with repository secrets and permissions.

[piatoss3612]

@claude
is this safe chage to give permission internal contributors to trigger claude github actions?

[github-actions]

Claude finished @piatoss3612's task in 1m 14s —— View job

---

Security Analysis

TL;DR: No, this change is NOT safe. It introduces a critical security vulnerability that allows any GitHub user to trigger the Claude workflow with your repository's secrets and permissions.

---

Critical Security Vulnerability

The current implementation has a fundamental flaw: it checks WHERE the PR came from, not WHO is commenting. This creates an authorization bypass that allows any GitHub user to trigger Claude on internal PRs.

Attack Scenario

1. An organization member creates a PR from a branch in chainapsis/keplr-example (not a fork)
2. Any random GitHub user comments @claude on that PR
3. The workflow triggers because github.event.pull_request.head.repo.full_name == github.repository is true
4. The author_association check is completely bypassed via the OR condition
5. The attacker now has Claude executing with your repository secrets and write permissions

Why This Happens

The logic uses OR conditions:

(author is OWNER/MEMBER/COLLABORATOR) OR (PR is from same repo)

This means if EITHER condition is true, the workflow runs. The second condition doesn't care who's commenting.

---

Additional Technical Issue

For issue_comment events (line 19), github.event.pull_request doesn't exist in the event payload. You're checking github.event.pull_request.head.repo.full_name, but this object is only available for pull_request, pull_request_review, and pull_request_review_comment events.

For issue_comment on a PR, you need to:

• Use github.event.issue.pull_request.url to detect if it's a PR
• Fetch PR details via GitHub API to get the head repo information

Reference: GitHub issue_comment event payload docs

---

Recommended Fix

Use AND logic to require BOTH a valid association AND same-repo for CONTRIBUTOR level:

if: |
  (
    (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude') &&
     (github.event.comment.author_association == 'OWNER' || 
      github.event.comment.author_association == 'MEMBER' || 
      github.event.comment.author_association == 'COLLABORATOR' ||
      (github.event.comment.author_association == 'CONTRIBUTOR' && 
       github.event.issue.pull_request != null && 
       /* fetch PR via API to check head repo */))) ||
    (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude') &&
     (github.event.comment.author_association == 'OWNER' || 
      github.event.comment.author_association == 'MEMBER' || 
      github.event.comment.author_association == 'COLLABORATOR' ||
      (github.event.comment.author_association == 'CONTRIBUTOR' && 
       github.event.pull_request.head.repo.full_name == github.repository))) ||
    (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude') &&
     (github.event.review.author_association == 'OWNER' || 
      github.event.review.author_association == 'MEMBER' || 
      github.event.review.author_association == 'COLLABORATOR' ||
      (github.event.review.author_association == 'CONTRIBUTOR' && 
       github.event.pull_request.head.repo.full_name == github.repository))) ||
    (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')) &&
     (github.event.issue.author_association == 'OWNER' || 
      github.event.issue.author_association == 'MEMBER' || 
      github.event.issue.author_association == 'COLLABORATOR'))
  )

This ensures:

• OWNER/MEMBER/COLLABORATOR can trigger from anywhere (existing behavior)
• CONTRIBUTOR can only trigger on non-fork PRs (your goal)
• Random users cannot trigger on any PRs (closes the vulnerability)

---

Alternative Approach

If private organization members truly appear as CONTRIBUTOR, consider:

1. Grant them MEMBER status in the organization (preferred)
2. Use a GitHub App with more granular permissions
3. Add specific users to an allowlist in the workflow

---

My Assessment

Do not merge this PR. The security risk outweighs the convenience. I recommend addressing the root cause (organization member permissions) rather than loosening the security model in a way that creates vulnerabilities.