# GitHub Bot PRs Now Trigger CI — With One Required Approval > Source: > Published: 2026-06-15 00:19:22+00:00 If you’re running AI coding agents — Kiro, Claude Code, Copilot, Codex — you’ve hit this wall. The agent writes code, opens a pull request as `github-actions[bot]` , and your CI does absolutely nothing. No tests run. GitHub blocked bot-created PRs from triggering workflows entirely. Teams were merging AI-generated code blind, or working around the restriction with `pull_request_target` , which is the kind of fix that trades one problem for a supply chain attack. On June 11, GitHub fixed the root cause — with the right security model attached. ## What Changed Pull requests created by `github-actions[bot]` can now trigger your CI/CD workflows. The catch — and this is intentional — is that a maintainer with write access must explicitly approve before any workflow runs. This matches the behavior already in place for Copilot-generated PRs. The behavior before this change was a bug dressed up as a security feature: bot PRs ran no CI at all, which meant teams were either merging without tests or resorting to dangerous workarounds. The scale of the problem makes this urgent. [GitHub processes 275 million AI agent commits per week in 2026](https://quasa.io/media/github-s-ai-agent-tsunami-275-million-commits-a-week-14-billion-projected-for-2026), with AI coding agents generating 17 million pull requests per month as of March — a 325% jump in six months. Claude Code alone accounts for roughly 4.5% of all public GitHub commits. When CI does not run on bot PRs, that is a massive surface of unverified code moving through your review queue. Research finds 1.7× more defects in AI-coauthored PRs compared to human-written code. The lack of CI was not harmless. ## Why the Old Workaround Was a Security Hole The standard workaround was `pull_request_target` , a GitHub Actions event that runs with the base repository’s full permissions — including all secrets — even when the triggering PR comes from a fork or bot. If the workflow checks out and executes code from the PR branch inside a `pull_request_target` run, you’ve handed an attacker your secrets and a privileged runner. [GitHub Security Lab calls this a “pwn request”](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/) and has documented it as one of the most common and dangerous GitHub Actions misconfigurations. This is not hypothetical. The tj-actions supply chain compromise hit 22,000 repositories through exactly this vector. Ultralytics had cryptominers injected into PyPI releases via GitHub Actions. [Orca Security’s research on pull request nightmares](https://orca.security/resources/blog/pull-request-nightmare-github-actions-rce/) documents the full exploit chain: attacker-controlled code running in a privileged CI context, with access to all secrets, with the ability to push commits and alter workflows. The safe alternative — use the `pull_request` event — was blocked for bot PRs. Until now. ## How the Approval Gate Works The security model is straightforward. A bot submits a PR. GitHub holds workflow execution. A maintainer reviews the code, clicks approve, and CI runs on the bot’s contribution exactly as it would on a human PR. Branch protections, required reviewers, and merge queue rules apply identically. This is one additional click that gives you the test signal you need before merging. There is one setting that deserves immediate audit: **Settings → Actions → General → “Allow GitHub Actions to create and approve pull requests.”** This must be OFF. If it’s enabled, a compromised workflow can create its own PR, approve it, and trigger CI — bypassing human review entirely. The 2026 default is disabled, but repos migrated from older configurations may have it on. The correct workflow configuration looks like this: ``` on: pull_request: types: [opened, synchronize, reopened] jobs: test: runs-on: ubuntu-latest permissions: contents: read steps: - uses: actions/checkout@v4 - run: npm test ``` Use `pull_request` , not `pull_request_target` . Set permissions explicitly to least privilege. Let the approval gate do its job. ## Three Changes, One Direction This bot PR fix did not ship alone. [GitHub Agentic Workflows moved to public preview on June 11](https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview/) — you write automations in natural language Markdown, GitHub compiles them into hardened Actions YAML, and Claude, Gemini, Copilot, or Codex handles the reasoning. Those agent-created PRs are now first-class CI citizens. The third change: Agentic Workflows no longer require a Personal Access Token. The built-in `GITHUB_TOKEN` works, eliminating long-lived credential management for automation pipelines. Taken together, this is GitHub signaling that agentic code generation is no longer a bolt-on workflow — it is the default model. The approval gate for bot PRs is not friction. It is the security contract that makes this viable at scale. ## What to Do Today Audit every repository where AI agents submit PRs. Look for `pull_request_target` triggers that check out PR branch code — those need to move to `pull_request` with the approval gate. Confirm “Allow GitHub Actions to create and approve pull requests” is OFF across your organization. And resist the urge to disable the approval requirement for speed. The one-click approval is the last human checkpoint before agent-written code runs in your infrastructure. That 30 seconds matters.