ci: gate @claude trigger on author association

[TheP2P (thep2p)]

Restrict the Claude (@claude) workflow to OWNER/MEMBER/COLLABORATOR so external users cannot trigger it on the public repo (protects the OAuth token quota).

[TheP2P (thep2p)]

Claude (@claude) review the PR

[claude]

Claude finished TheP2P (@thep2p)'s task —— View job

---

PR Review: Gate Claude (@claude) trigger on author association

• Read .github/workflows/claude.yml
• Analyze the author-association gating logic
• Post review feedback

---

Overall: LGTM. This is a solid, minimal security hardening change. The author_association gate is applied consistently across all four trigger paths, and the allow-list (OWNER, MEMBER, COLLABORATOR) correctly excludes untrusted actors (CONTRIBUTOR, FIRST_TIME_CONTRIBUTOR, NONE), which achieves the stated goal of protecting the OAuth token quota on the public repo.

What's correct

• Consistent coverage — each event branch (issue_comment, pull_request_review_comment, pull_request_review, issues) uses the matching association field (comment.author_association, review.author_association, issue.author_association). No path is left ungated. ✅
• Correct allow-list semantics — author_association is computed by GitHub server-side from the actor's real permission on the repo, so it can't be spoofed by the comment author. Using an explicit allow-list (rather than a deny-list) is the safer choice. ✅
• Read-only permissions — the job keeps least-privilege read scopes, so even a bypass wouldn't grant write. ✅

Observations / optional considerations (non-blocking)

1. author_association reflects repo permission, not org membership nuance. For a public repo this is exactly what you want. Just note that MEMBER means "member of the org that owns the repo" — if the org has broad membership, anyone in the org can still trigger. If you want to tighten further later, you could drop to OWNER/COLLABORATOR only. Not needed for this PR.

2. Re-trigger via assigned events. The issues: [opened, assigned] trigger gates on issue.author_association — the issue author's association, not the assigner's. This is fine given the current if also requires @claude in the body/title, but worth keeping in mind: a trusted user opening an issue with @claude sets author_association to that trusted user, which is the intended behavior.

3. pull_request_review_comment from forks. GitHub only sends this event to the base repo with base-repo secrets when the actor has the appropriate association, and your gate re-checks it — good defense in depth.

Security note on the broader pattern

Because these workflows run on issue_comment / pull_request_review (which execute in the base repo context with access to secrets), gating on author_association is the right primary control. The change does not check out or execute PR-head code in a privileged step, so there's no obvious pwn-request surface introduced here.

No changes requested — this is ready to merge.
• Branch: ci/gate-claude-trigger

[S T (staheri14)]

LGTM!