## TL;DR

Secrets are deliberately withheld from fork PRs to prevent exfiltration by untrusted code. Restructure the workflow so untrusted PRs do not need secrets, or gate secret-needing jobs behind maintainer approval.

## Error

```text
github actions failed: secret not available to fork pr
```

## Steps

1. Confirm the PR is from a fork; internal PRs get secrets, forks do not. Expected: the policy cause confirmed.
2. Split the workflow: run untrusted steps (build, test) without secrets on the fork PR. Expected: those jobs go green.
3. Gate secret-needing jobs (deploy, publish) behind an explicit approval or run them only after merge. Expected: secrets stay protected.
4. For required checks, use environments with required reviewers for the privileged jobs. Expected: human gate before secret use.
5. Document the pattern for contributors so fork PRs are not surprised. Expected: fewer confused issues.

## When to use

- Fork PR workflows failing on secrets.
- Designing contributor-friendly CI.

## When not to use

- Secrets missing on same-repo PRs (check the secret name and mapping).
- You are tempted to expose secrets to forks (do not).

## Tool compatibility

- GitHub Actions; environments and required reviewers.

## Variant phrasings

### secrets empty in fork pull request

By design.

### github actions secret not passed to fork

Same policy.

## Why it happens

Fork code is untrusted; a workflow that hands it secrets lets any contributor print them. The platform withholds them by default.

## Edge cases

- `pull_request_target` runs in the base context and sees secrets; misuse of it reintroduces the exfiltration risk.
- Required status checks must be satisfiable without secrets or forks can never go green.
- Dependabot PRs have their own secret scoping; check it separately.

## Provenance

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