Why did my automation's pull request not trigger CI checks?

Events created with the repository's GITHUB_TOKEN generally do not start new workflow runs, which stops accidental loops. If your automation opens a pull request with that token, your CI may never run on it. Use a GitHub App or another scoped credential if checks must run, and keep that credential narrow.

What GitHub says

GitHub's documentation for events that trigger workflows states that, with the exception of workflow_dispatch and repository_dispatch, events triggered by the GITHUB_TOKEN do not create workflow runs. The reason is recursion: without this rule, a workflow that pushes a commit would trigger itself forever.

Related rules exist elsewhere. For check_run and check_suite events, the docs say they do not trigger workflows when the check suite was created by GitHub Actions, again to prevent recursion.

The symptom

Your security automation opens a fix pull request. The branch has a new commit. Required status checks never appear, so the pull request cannot merge under branch protection. People assume the automation is broken. It is behaving as designed.

Options, from safest to riskiest

1. Let a human nudge it. A reviewer closes and reopens the pull request, or pushes an empty commit. Slow, but zero new credentials.
2. Dispatch the checks explicitly. Because workflow_dispatch and repository_dispatch are exempt, the automation can call one of them to start a test workflow. The result then needs to be reported as a status on the right commit, which takes extra work.
3. Use a GitHub App installation token. The documentation recommends creating a GitHub App and generating an installation access token when you need permissions the GITHUB_TOKEN lacks. The recursion rule is written for the GITHUB_TOKEN, so it does not cover events created with an app token. The app can be limited to chosen repositories and permissions.
4. Use a personal access token. The docs list this as an alternative, but it ties the automation to a person and usually carries broader reach. Avoid it for anything that matters.

The risk of bypassing the rule

The recursion rule is also a safety brake. Once your automation can trigger CI, a bug can create a loop: open pull request, CI runs, automation reacts, opens another. Add guards:

• Cap the number of open automation pull requests per repository.
• Mark automation branches with a fixed prefix and make the workflow ignore its own prefix.
• Add a concurrency group so runs cannot overlap, as in stopping a job from running twice.
• Keep fix pull requests subject to required reviews. Our post on required status checks for automated fix PRs explains the checks to require.

Least privilege for the credential

Whatever credential you choose, give it the minimum. GitHub's guidance says to grant the GITHUB_TOKEN the least required access using the permissions key, and the same thinking applies to an app token. For a fix PR bot that usually means contents write and pull requests write on selected repositories, nothing about administration or secrets. See least privilege token permissions for security automation.

Quick check

Sources

• GitHub Docs: events that trigger workflows
• GitHub Docs: use GITHUB_TOKEN for authentication in workflows

Safeguard's autonomous remediation opens fix pull requests, is off by default, and every category starts on Manual, so a human approves each change. Try the free scan at gold.safeguard.sh/scan.

Last reviewed: 19 October 2026.