For public repositories, GitHub asks you to approve workflow runs from fork pull requests, and the default covers all first-time contributors. The strictest option covers every external contributor. Fork workflows also run without your secrets, but a pull_request_target workflow behaves differently and ignores these settings.
Public repositories
In the repository's Actions settings, GitHub offers three approval levels for fork pull request workflows:
- Require approval for first-time contributors who are new to GitHub.
- Require approval for first-time contributors, which is the default.
- Require approval for all external contributors.
External means anyone who is not a repository member or owner, and not a member of its organization.
The caveat with the first two
With the first two options, anyone who has ever had a commit or pull request merged into the repository skips approval from then on. One small merged typo fix is enough. If your build runs anything powerful, that is a weak gate.
For repositories with sensitive workflows, the third option is the safer choice. It costs a click per run.
What a fork workflow can see
GitHub's documentation says workflows from forks do not get sensitive data such as secrets. That default is the reason a fork can run tests without leaking your deploy key.
The exception to remember
Workflows triggered by pull_request_target run in the context of the base branch and always run, whatever the approval settings say. That trigger can see secrets, so it must never check out and run code from the fork. For the full discussion, see pull_request_target vs pull_request fork safety.
Private repositories
Private repositories have different switches. You can allow fork pull request workflows to run with a read-only token and no secrets. Separate options let you send write tokens, or send all secrets, to pull request workflows, and another requires approval from someone with write permission. If an organization policy turns an option off, a repository cannot turn it on.
Leave the write token and secrets options off unless you have a specific, reviewed reason.
A review checklist
- Set approval to all external contributors for repositories with release or deploy workflows.
- Search your workflows for pull_request_target and justify each use.
- Keep the default token permissions read-only.
- Read the diff of a workflow file change before you approve any run.
Try it yourself
Click through it at your own pace, or open it full screen. Watch where a failing check stops the merge.
Quick check
Does approval protect me if the contributor already had a commit merged?
Under the two first-time options, no. They skip approval. Choose all external contributors if that matters.
Do fork workflows get my repository secrets?
Not by default for public repositories. The pull_request_target trigger is the notable exception to understand.
Sources
Last reviewed: 19 October 2026.
