review workflow failed on fork PR: secrets are not available to pull requests from forks

TL;DR

Workflows triggered by pullrequest run without secrets on forks, by design, so fork code can never exfiltrate them. Split the workflow: untrusted build steps stay on pullrequest, and a separate privileged workflow on pullrequesttarget does the secret-needing work after checking out a pinned SHA. Gate the privileged run on a maintainer-added label so random forks cannot trigger it at will.

The error

review workflow failed on fork PR: secrets are not available to pull requests from forks

Steps

1. Confirm the trigger is the problem

Open the workflow and check the on: key. If it says pull_request and the failing PR is from a fork, the missing secrets are expected behavior, not a misconfiguration. Expected output: you can see the trigger and the fork source line up.

2. Split off the privileged steps

Move the steps that need secrets (posting review comments, uploading coverage, calling external APIs) into a second workflow triggered by pull_request_target. Keep the build and test steps on pull_request. Expected output: two workflows with a clean trust boundary between them.

3. Check out a pinned SHA in the privileged workflow

In the pullrequesttarget workflow, check out the base first, then fetch the PR head by its SHA from the event payload. Never check out a branch name from the fork, which the author can move after you review it. Expected output: the privileged run operates on exactly the reviewed code.

4. Gate on a maintainer label

Require a label like "safe to review" that only maintainers can add before the privileged workflow does anything with secrets. Check for the label at the start of the job and exit early without it. Expected output: fork PRs do nothing privileged until a maintainer opts in.

5. Pass results between workflows with artifacts

Have the untrusted workflow upload its results as artifacts, and let the privileged workflow download and post them. Secrets never cross into the untrusted run. Expected output: the review posts on the fork PR with no secret exposure.

When to use

• The exact secrets-on-forks failure
• Review bots that must comment on external contributions
• Coverage or analysis uploads that need credentials on fork PRs

When not to use

• Secrets missing on same-repo PRs (a real misconfiguration)
• Workflows that do not need secrets at all
• Private repos where forks are internal

Tool compatibility

• GitHub Actions pullrequest and pullrequest_target events
• upload-artifact and download-artifact actions for handoff
• Branch protection and environment reviewers as extra gates

Variant phrasings

secrets not available to pull requests from forks

Same fix. This is platform behavior, not a bug in the workflow.

how to run CI with secrets on fork PRs safely

The split-workflow pattern with label gating is the documented safe approach.

pullrequesttarget security best practices

Pin the SHA, gate on a label, and keep the privileged steps minimal.

Why it happens

pullrequest workflows check out and execute fork code with the repo's secrets in scope, which would let a malicious PR print them to the log. GitHub removes secrets from that context entirely. pullrequest_target runs in the base repo context with secrets, which is why it must never blindly execute fork code.

Edge cases

• The label gate is only as strong as who can add labels. Restrict label permissions to maintainers.
• Re-running a privileged workflow after new pushes re-fetches the SHA. Always re-resolve, never cache the checkout.
• Artifacts from the untrusted run are untrusted content. Treat them as such when posting.
• Draft fork PRs: decide whether drafts get the label at all, and document the policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GrsPJ8cX12qPnRtosaKA