ci: gate claude.yml on same-repo PRs and pin actions to commit SHAs #1882

Rewritten 2026-08-10. This issue was originally filed as a fork-PR sandbox-escape concern raised by GitHub Copilot during review of #1869. The repo has since been confirmed to run pull_request_creation_policy: collaborators_only, which retires most of that threat model. The surviving work is narrower and is what this issue now tracks. The original framing is preserved in the collapsed section at the bottom.

What this issue is now

Two pieces of hardening on .github/workflows/claude.yml, plus one finding that turned out to need no code change.

1. Gate the PR-head checkout and the Claude run on same-repo PRs

.github/workflows/claude.yml checks out the PR head repo:

- name: Checkout PR branch
  if: steps.pr.outcome == 'success'
  uses: actions/checkout@v6
  with:
    ref: ${{ steps.pr.outputs.sha }}
    repository: ${{ steps.pr.outputs.repo }}
    fetch-depth: 0

steps.pr.outputs.repo is pr.data.head.repo.full_name — for a fork PR, the fork. Run Claude Code then executes in that checkout with ANTHROPIC_API_KEY in the environment and --allowedTools "Bash,mcp__mcp-docs".

Why this is no longer the emergency it was filed as. Two settings stand between an outside contributor and that checkout:

1. pull_request_creation_policy: collaborators_only (verified against the repo API on 2026-08-10) — non-collaborators cannot open a PR here at all, so the untrusted fork PR mostly does not exist. Note allow_forking is still true; forks exist, they just can't open PRs.
2. Author-association gate — every trigger arm requires OWNER / MEMBER / COLLABORATOR, so a PR author cannot self-trigger the workflow unless they are already in that set.

The residual path, and why it is still worth closing. The trigger gate keys on author_association, and MEMBER means member of the modelcontextprotocol org — a materially larger set than "has write on this repo." If GitHub counts org members as collaborators for the purposes of collaborators_only, an org member with no write access here could open a fork PR and self-trigger @claude on it. That has not been tested, and the setting is new enough that it should be tested rather than assumed.

Either way, the mitigation currently lives entirely in a repo setting rather than in the workflow. A setting can be flipped by anyone with admin, in a UI with no review and no diff. The gate belongs in the file.

Proposed shape — have the Get PR details step emit an is_fork output, then:

Refusing outright on a fork PR is deliberate. The alternative floated in the original write-up — fall through to a "metadata-only" review against the base tree — trades an untrusted-code problem for a wrong-tree problem, which is the other half of what Copilot flagged. Better to decline visibly than to post a confident review of a tree that isn't the one under review.

2. Pin the actions to commit SHAs

actions/checkout, actions/github-script, and anthropics/claude-code-action are all referenced by mutable major tags. This is independent of the fork question — it is ordinary supply-chain hygiene on a workflow that handles ANTHROPIC_API_KEY and grants Bash. A compromised or force-moved tag on any of the three is an unreviewed code change inside a secret-holding job.

Pin each to a full commit SHA with a trailing # vX.Y.Z comment, which is the form Dependabot reads and keeps updated — so pinning does not cost us upgrade automation.

⚠️ Coordinate with #1922. The open Dependabot PR bumps actions/checkout v6 → v7 and actions/github-script v8 → v9 in this same file. Pin to the v7 / v9 SHAs so this doesn't regress those bumps; Dependabot will rebase #1922 and drop its now-redundant claude.yml hunks, leaving its main.yml changes intact.

3. The failure-fallback concern — no change needed

Copilot's mirror-image finding was that when the PR-lookup step fails, the workflow falls back to checking out the base repo but still runs Claude, reviewing the wrong tree while spending secrets and minutes.

On inspection this does not happen. Checkout repository is guarded by if: steps.pr.outcome != 'success', which contains no status-check function, so GitHub applies an implicit success() — when a prior step has failed, the step is skipped regardless of the outcome comparison. The failure path already declines to run. Worth stating explicitly in the workflow so the next reader doesn't re-derive it, but there is no bug to fix.

Verification

The workflow only runs from the default branch, so a change here is not exercised until it reaches main at the next milestone merge. After that, verify with a real @claude invocation on a same-repo PR (must still check out the PR head and review it) and, if a fork PR can be produced, that it is declined with the summary message rather than silently reviewing the wrong tree.

Out of scope

Copilot's other comment on #1869 — that issues: read / pull-requests: read prevents @claude from posting — is factually incorrect and needs no action. claude-code-action mints its own GitHub App token via id-token: write; the permissions: block scopes GITHUB_TOKEN, not that app token. claude[bot] posted on #1825 on 2026-07-27 under exactly these permissions, ten days after ac3c1a12 (2026-07-17) last touched the file. The read-only grants are correct and must not be widened.

Priority

Re-scored Low (5/16), down from Medium (8/16). The original score rested on the fork exposure being live; collaborators_only makes this hardening rather than remediation.

- name: Checkout PR branch
  if: steps.pr.outcome == 'success'
  uses: actions/checkout@v6
  with:
    ref: ${{ steps.pr.outputs.sha }}
    repository: ${{ steps.pr.outputs.repo }}
    fetch-depth: 0