Before you click Approve workflows to run on a fork pull request, read the diff, look hardest at changes under .github/workflows, and confirm the change does not run attacker-controlled code with your secrets. Approving a run means you decided that the code it executes is acceptable.
What the approval gate is
GitHub says workflow runs triggered by a fork pull request may need manual approval from a maintainer with write access. The requirement can be configured at repository, organization and enterprise level. Runs left waiting for more than 30 days expire and are marked as failed.
The point of the gate is simple. CI executes whatever the pull request contains, such as test scripts, build files and the workflow itself. Without a human check, anyone could submit a pull request that runs their code on your runner.
The checklist
Read the diff before you approve, and look for these in order:
- Workflow changes. GitHub's own guidance is to pay particular attention to changes in the workflows directory. A "docs fix" that edits a workflow deserves a question.
- Build and test scripts. Files such as package scripts, Makefiles, setup scripts and test configs all run during CI.
- New or changed dependencies. Check the package names. Typosquats are a familiar trick.
- Network calls. Any new download or upload in a script.
- Encoded or obfuscated blobs. Long base64 strings and minified code in a small patch.
- Who the author is. A first-time contributor with a large, odd change is a reason to slow down. It is not proof of bad intent.
Know what your workflow can reach
Approval is safer when the workflow has little to steal. Review these separately:
- Whether the workflow triggers on pull_request or pull_request_target. The second runs in the context of the base repository and needs far more care. See pull_request_target vs pull_request.
- Which secrets the job can read.
- The token permissions the job gets. Set them to the minimum, as in least privilege GitHub Actions token permissions.
Set the policy to match your capacity
A strict approval requirement costs a click for each new contributor. For a small project that is a fair price. If you drop to a looser setting to reduce friction, make sure your workflows hold no secrets that matter and run with read-only tokens.
Approve in the right order
If a pull request edits both application code and a workflow, ask the author to split it. Merge or review the workflow change on its own, with a second reviewer if you have one. Mixed changes hide the risky part.
Quick check
What happens if I never approve the run?
After 30 days it expires and is marked as failed. The pull request itself is not affected.
Is a green check proof the change is safe?
No. Tests passing says the code behaves under the tests. It says nothing about what else the code might do.
Sources
Last reviewed: 19 October 2026.
