Required status checks for automated fix PRs: what to enforce

Require build, unit tests, a dependency or vulnerability check and a policy gate on every automated fix PR, and enforce them with branch protection so a bot cannot merge around them. Also check that your checks actually run on bot PRs, because workflow triggers can behave differently when a token opens the PR.

The minimum set

For a dependency or code fix, these checks are a reasonable floor:

1. Build. The project compiles and packages with the change.
2. Unit and integration tests. At least the suites that touch the changed module.
3. A vulnerability and license check. The fix should not introduce a new finding that your policy blocks.
4. A policy gate. One check that evaluates your written rules, such as no new critical findings and no disallowed licenses.
5. Lockfile integrity. An install that fails if the lockfile and manifest disagree.

The demo below shows a gate on a pull request.

Click through it at your own pace, or open it full screen.

How branch protection enforces them

GitHub protected branches let you mark checks as required. A required check must report successful, skipped or neutral before merging. Note the skipped case: a check that is skipped counts as passing, so make sure path filters do not skip your important checks on dependency changes.

You can also restrict a required check to a specific GitHub App as its source, so that a random status with the same name cannot satisfy it. And you can require branches to be up to date before merging, so checks run against the latest base.

Merge queues for busy branches

A merge queue tests each pull request together with the latest base branch and the PRs ahead of it. That helps when many fix PRs arrive at once, since two individually green upgrades can conflict. If GitHub Actions provides your required checks, the workflow must listen for the merge_group event, or the required check is never reported and the merge fails.

The bot trigger gotcha

GitHub documents that events triggered by the GITHUB_TOKEN will not create a new workflow run, with workflow_dispatch and repository_dispatch as exceptions. So if a remediation tool opens a PR using that token, your pull request workflows may not start, and a required check will sit pending forever. The usual fixes are to open PRs with a GitHub App or another credential designed for that purpose, or to dispatch the workflow explicitly. Test this on a throwaway PR before you rely on it. See also least privilege for a remediation bot token.

Do not let the bot bypass the rules

By default, admins and roles with bypass permission are exempt from branch protection. If the bot has such a role, your gates are decoration. Remove the bypass, or give the bot a role without it.

Quick check

Safeguard can enforce policies and gates on pull requests, and its fix PRs are meant to pass through them like any other change.

Sources

• About protected branches (GitHub Docs)
• Managing a merge queue (GitHub Docs)
• Triggering a workflow (GitHub Docs)

Last reviewed: 19 October 2026.