What was broken before this
A common automation pattern: a scheduled workflow runs, makes some change (dependency bumps, generated docs, a lockfile refresh), commits it, and opens a pull request using github-actions[bot] as the author. Before this change, that bot-authored PR could not trigger the repo’s own CI workflows at all, no lint, no test, no build check.
That’s a real gap. It meant bot-generated PRs either sat unchecked until someone manually re-ran the workflow, or worse, got merged without the same test/lint/build gate a human-authored PR would have gone through automatically. GitHub’s own framing of the fix is direct about why the fix isn’t “just let it run automatically” either:
“Requiring approval is a security measure to ensure generated code does not automatically run workflows which may have access to sensitive information.”
So the fix isn’t unrestricted trust, it’s a middle ground: bot PRs can now run workflows, but a human has to say so first, every time.
How the approval gate works in practice
This builds on a setting that already existed: repository Settings → Actions → General → Workflow permissions, specifically the checkbox controlling whether GitHub Actions can create and approve pull requests. That checkbox is what lets a scheduled workflow open the PR in the first place. What’s new as of 2026-06-11 is what happens after the PR exists.
Once github-actions[bot] opens a PR against a workflow-triggering event (pull_request, for instance), the workflow run doesn’t start immediately the way it would for a normal contributor with write access. It sits pending, waiting for approval, visible the same way a first-time contributor’s workflow run already waited for maintainer approval before this change. A collaborator with write access reviews the PR’s diff and clicks approve on the workflow run, and only then does CI actually execute.
GitHub notes this matches an existing pattern rather than inventing a new one:
“This matches the behavior of Copilot-generated pull requests.”
If your team already reviews Copilot PRs’ workflow runs this way, bot-authored PRs from your own scheduled automation now follow the identical flow.
Structural Comparison Matrix
| Operational Aspect | Before | After (2026-06-11+) |
|---|---|---|
| CI workflow trigger on a bot-authored PR | Never triggered, no gate to pass | Triggered, pending human approval |
| Risk of merging unchecked generated code | Real: no CI ran unless manually re-run | Reduced: CI runs once approved |
| Approval requirement | N/A (nothing to approve) | Collaborator with write access |
| Consistency with Copilot-authored PRs | Different handling | Same approval flow |
Reviewing and approving a pending run
If your repo runs a scheduled workflow that opens PRs (a dependency-bump job, a generated-content refresh, anything committing via GITHUB_TOKEN), check for pending runs after this change ships rather than assuming CI already ran:
- Open the pull request from
github-actions[bot]in the GitHub UI. - Look for the workflow run status. A pending approval shows as a banner on the PR, distinct from a normal “in progress” or “queued” state.
- As a collaborator with write access, review the PR’s actual diff first, this is the security check the changelog describes, not a rubber stamp.
- Click Approve and run on the workflow run to let it execute.
If you want bot PRs to keep working exactly as before this change, and you’re comfortable with the tradeoff, there’s no toggle to bypass the approval step entirely; it’s the intended behavior, not an opt-in feature.
This doesn't change who can commit via GITHUB_TOKEN
The existing repository setting for whether Actions can create and approve pull requests still governs whether a workflow can open a PR at all. This change only affects what happens after that PR exists: whether its own triggered workflow runs automatically or waits for a person.
Source
GitHub’s changelog entry on the bot-PR approval requirement (2026-06-11). Browse more posts like this in the Dev Tools archive.
