Required checks for AI pull requests: the same gates as a human

By Kaveh Alemi·Latchkey

Required checks for AI pull requests only hold if CI actually reports on the agent's latest commit, from an event GitHub counts, set by the source you expect. Pin each required check to the GitHub Actions app, require an approval from someone other than the last pusher, put workflow files under CODEOWNERS, and make sure the agent's pull requests are created by an identity whose events start workflows.

A ruleset treats every pull request the same, which is what you want: the agent's branch merges on the same evidence as yours. The failures are all upstream of the ruleset. The check never started, it started from an event that does not count, it is waiting on a human, or it was set by something other than your CI.

Each of those looks like the same yellow dot in the merge box. The sections below separate them, starting with the one that has nothing to do with your ruleset at all.

Why an agent pull request can have no checks

The first cause is the token. On github.com a pull request a workflow opens with GITHUB_TOKEN now gets its runs in an approval-required state, and a push with that token gets none; testing AI-generated pull requests in CI has the rule and its exceptions.

The second is Copilot cloud agent, whose workflows by default do not run until a user with write access clicks Approve and run workflows. The third is quieter: checks from a workflow started by workflow_dispatch on the head branch do not appear on the pull request and do not satisfy a required status check, even if they pass on the same commit. Only push, pull_request, pull_request_review, pull_request_target, deployment and deployment_status count, plus merge_group for a merge queue.

A ruleset that pins the source of each check

Any person or integration with write access can set the state of any status check in the repository. That matters more with agents than with people: an agent holding a write-capable token can post a commit status named test with state success, and a ruleset that accepts any source counts it. Rulesets let you name the app that must report each check; for Actions that is the github-actions app, ID 15368.

The same ruleset can require the pull request rule with an approval from someone other than the last pusher, so whoever pushed last, an agent identity or a person, can never be the approval that covers that push. strict_required_status_checks_policy requires the branch to be up to date before merging, so the checks ran against the code that will actually land.

gh api --method POST repos/OWNER/REPO/rulesets --input - <<'EOF'
{
  "name": "main: same gates for everyone",
  "target": "branch",
  "enforcement": "active",
  "conditions": { "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } },
  "rules": [
    { "type": "pull_request", "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": true,
        "require_last_push_approval": true,
        "required_review_thread_resolution": false } },
    { "type": "required_status_checks", "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [
          { "context": "test", "integration_id": 15368 },
          { "context": "lint", "integration_id": 15368 } ] } }
  ]
}
EOF

Reviews: who may approve agent work

Three settings decide whether a human actually looks. Require approval of the most recent reviewable push, so new commits from the agent after an approval need another one. Dismiss stale approvals when the diff changes, if you would rather start over than trust the last approver to re-read. And leave Allow GitHub Actions to create and approve pull requests switched off unless a workflow genuinely needs it: that setting is what decides whether a workflow's GITHUB_TOKEN can approve pull requests at all.

GitHub adds two Copilot-specific rules on top. The user who asked Copilot cloud agent for a pull request cannot approve it. And a ruleset requires one extra approval when Copilot opens a pull request under its own app identity rather than on behalf of a person; that setting is on by default, in public preview, and has no effect on rulesets that require zero approvals.

CODEOWNERS for the files that change what CI means

An agent that edits .github/workflows/ is editing its own examiner, and a lockfile or test config change alters what a green check proves. With code owner review required, any pull request touching an owned path needs an approval from one of its owners, who must have write access. The last matching pattern in the file wins, so put these lines at the end.

# Changes to CI itself need a platform owner, whoever wrote them.
/.github/workflows/ @your-org/platform
/.github/CODEOWNERS @your-org/platform
package-lock.json @your-org/platform

Checks that skip are checks that block

Agents produce narrow diffs, which makes path filters bite. A workflow skipped by a paths or branches filter leaves its required checks Pending, and the merge box waits with Waiting for status to be reported. A job skipped by its own if: condition reports Success instead. So require jobs that always run and decide inside, rather than whole workflows that sometimes do not.

The same logic covers the agent's own loop. A check the agent dispatched does not count, so let it dispatch for speed, but make the required run come from pull_request. If you use a merge queue, add merge_group too, or the queued pull request waits for a check that never starts. The full set of trigger rules for agent pull requests is on testing AI-generated pull requests in CI, and the approval banner itself on waiting for approval to run workflows.

on:
  pull_request:
  merge_group:
jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      code: ${{ steps.filter.outputs.code }}
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - id: filter
        if: github.event_name == 'pull_request'
        run: |
          git fetch --no-tags --depth=1 origin "$GITHUB_BASE_REF"
          if git diff --name-only FETCH_HEAD HEAD | grep -qv '^docs/'; then
            echo "code=true" >> "$GITHUB_OUTPUT"
          fi
  test:
    needs: changes
    if: needs.changes.outputs.code == 'true' || github.event_name == 'merge_group'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - run: npm ci && npm test

What this page is built on

Documentation, read on 2026-11-12: the docs.github.com pages on required status checks, rulesets, GITHUB_TOKEN and Copilot cloud agent, GitHub's changelog, and the REST reference for the ruleset payload. No recorded run backs it and there is no evidence entry for it in this repository. The ruleset call above was not sent against a live repository from here, so check its response in your own before you rely on it.

Key takeaways

• On github.com, GITHUB_TOKEN pull requests now get approval-required runs; a push with that token still gets none.
• Checks from workflow_dispatch never satisfy a required status check, even on the same commit.
• Pin each required check to the GitHub Actions app (integration_id 15368) so a token cannot post a fake green.
• Require approval of the last push and CODEOWNERS on workflow files, and keep Actions from approving pull requests.

Frequently asked questions

Related guides

References

• GitHub Docs: troubleshooting required status checks (read 2026-11-12)
• GitHub Docs: available rules for rulesets
• GitHub Docs: GITHUB_TOKEN, when it triggers workflow runs
• GitHub changelog: bot-created pull requests can run workflows if approved
• GitHub Docs: Copilot cloud agent risks and mitigations
• GitHub Actions documentation