Open the pull request, read the Files changed tab, look closely at anything under the workflows directory, and then approve the run or leave it. GitHub states that runs waiting for approval for more than 30 days expire and are marked as failed, so a short weekly routine keeps the queue honest.
Why runs wait
For a public repository, workflow runs triggered by a contributor's pull request from a fork may need manual approval from a maintainer with write access. This applies to first time contributors by default, and you can configure approval requirements for a repository, organization or enterprise. Until approved, no job starts, so no contributor code runs on your runners.
The approval procedure from GitHub's docs
- Open the pull request from the Pull requests list.
- Click Files changed.
- Inspect the changes and confirm you are comfortable running your workflows on the branch.
- Watch for any change in the workflows directory.
- Click Awaiting approval, then Approve workflows to run.
That is the entire mechanism. The skill is in step three.
A five minute review
| Look at | Red flag |
|---|---|
| Workflow files | Any edit by an outside contributor |
| Package scripts such as test or install hooks | New commands that download or run something |
| Dependency manifests and lockfiles | New packages, unusual registries, git URLs |
| Build files | Network calls, base images changed |
| Size and scope | A large unrelated change in a tiny fix |
If the pull request changes tests and the scripts are untouched, approving is routine. If it edits the pipeline, do not approve until the owners have read it.
A weekly queue routine
- Filter open pull requests with pending approvals.
- Sort by age. Anything near the 30 day limit gets a decision or a comment.
- Reply to the contributor with what you need, such as a rebase, tests or a split.
- Close stale ones politely rather than letting them expire into failures.
- Record repeated problem patterns, and add them to CONTRIBUTING.
Reduce the load
- Write a short CONTRIBUTING section that lists the checks and how to run them locally.
- Use labels for pull requests that need security review.
- Auto-close pull requests with no response after a stated period, announced in advance.
- Spread approval rights across several maintainers, not one person.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a queue is sorted and worked by priority, the same habit that keeps an approval queue short.
Where Safeguard fits
Safeguard's dependency scanning, policies and gates help you decide on the dependency side of a contributor change. A free scan shows what it would flag.
Quick check
What happens to a run nobody approves?
After more than 30 days it expires and is marked as failed, with an annotation explaining why.
Who can approve a fork run?
A maintainer with write access to the repository.
Sources
Last reviewed: 19 October 2026.
