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

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.

The four places an agent pull request stalls or slips through, in the order it meets them.

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.

Runs left awaiting approval for more than 30 days expire and are marked as failed, per GitHub's page on approving workflow runs from forks.

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

Parameter names from the REST reference for repository rulesets. 15368 is the id returned by GET /apps/github-actions, read on 2026-11-12. The context must match the check name your job reports, which is the job name unless you set one.

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

GITHUB_BASE_REF is only set on pull_request and pull_request_target, so the diff step runs only there and a merge_group run always tests. A job skipped by its if: reports Success, which is what keeps a docs-only pull request mergeable.

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.

FAQ

Why does my pull request say "Waiting for status to be reported"?

A required check has not reported on the latest commit. The usual causes are a workflow skipped by a path or branch filter, a run waiting for approval, or a check that only ran from workflow_dispatch, which GitHub does not evaluate for pull requests. Checks from earlier commits do not count.

Why are workflows not running on a pull request created by GitHub Actions?

Because it was created with GITHUB_TOKEN. On github.com the opened, synchronize and reopened events now create runs that wait for approval from someone with write access. To have them start unattended, create or update the pull request with a GitHub App installation token or a personal access token.

Can a bot approve its own pull request to satisfy required reviews?

Not if you configure against it. Require approval of the most recent reviewable push from someone other than the pusher, keep Allow GitHub Actions to create and approve pull requests off, and note that Copilot cloud agent cannot approve or merge, and the user who prompted it cannot approve its pull request.

Do checks from workflow_dispatch count as required status checks?

No. GitHub only evaluates checks from workflow runs triggered by push, pull_request, pull_request_review, pull_request_target, deployment and deployment_status, plus merge_group for merge queues. A dispatched run can pass on the head commit and still leave the required check waiting.

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