GitHub's agentic autofix is GA: batching 25 CodeQL alerts into one draft PR, what it bills, and how to review the fixes

GitHub made agentic autofix for code-scanning alerts generally available on October 15. Per the changelog, it fixes alerts "the way a developer would": it explores the relevant files, proposes a fix, and reruns CodeQL to confirm the alert is closed before it opens a pull request. You can hand it up to 25 alerts at once and get them back in a single draft PR.

That makes it a candidate for the backlog every repository with CodeQL has: the few hundred medium-severity alerts nobody has had time for. This is how to try it on that backlog without merging a fix that turns CodeQL green and quietly changes behaviour.

Who can use it

• Plans: GitHub Code Security or GitHub Advanced Security customers on GitHub Enterprise Cloud, including Enterprise Cloud with data residency.
• Alerts: backlog alerts on the repository's default branch only. The changelog says alerts "detected only on pull requests or other branches cannot be assigned to Copilot."
• Licences: the docs state no GitHub Copilot licence is needed for the person assigning the alert. The enterprise needs a Copilot billing method set up, though.

Turning it on

1. An enterprise owner enables agentic autofix in the enterprise's Advanced Security policies.
2. An organization or repository admin then turns it on in the Code Security settings.
3. Set a budget before anyone assigns alerts (next section).

What it costs

Each session draws on two meters:

• Code Security AI credits, shown under "AI usage" in enterprise billing. Organizations can set a SKU-level budget for Code Security AI credits.
• GitHub Actions minutes, because the agent runs in Actions and reruns CodeQL to validate its fix.

GitHub does not publish a per-alert price, and cost will vary with how much of the repo the agent has to read and how long your CodeQL analysis takes. The honest way to find out is to run one small batch and read the bill. Set the budget first so a 25-alert experiment cannot become a surprise.

Picking a first batch

Start with alerts that are easy to verify, not the scariest ones. List open default-branch alerts and group them by rule with the gh CLI (replace the owner, repo and branch):

gh api --paginate 'repos/OWNER/REPO/code-scanning/alerts?state=open&ref=refs/heads/main&per_page=100' \
  --jq '.[] | [.rule.id, .rule.security_severity_level // "none", .most_recent_instance.location.path] | @tsv' \
  | sort | cut -f1,2 | uniq -c | sort -rn | head -20

Good first batches share a rule and have tests nearby: ten instances of the same missing-escape or unsafe-format rule in code you already cover is a much better trial than 25 unrelated alerts across the repo. One rule per PR also makes review far faster, because you check the same pattern repeatedly.

Assigning the alerts

• One alert: repository → Security and quality tab → Code scanning → open the alert → under Assignees, Assign to Copilot.
• A batch: in the code-scanning alert list or a security campaign, select up to 25 alerts and click Assign to Copilot above the list.

The docs say a draft PR "typically" appears within a few minutes, authored by Copilot, with a summary of the fix, why it closes the alert, and the validation steps it took. The agent session log has the detail. To ask for changes, mention Copilot in a PR comment and it will iterate.

Reviewing the fixes

The PR is a draft for a reason. GitHub's own docs say Copilot "validates fixes on a best-effort basis," and that it will say so in the PR when it cannot validate a fix or suspects a false positive. A rerun of CodeQL proves the alert pattern is gone. It does not prove the code still does what it did. Use this checklist on every PR:

1. Read the PR's own caveats first. Any fix flagged as not validated or a likely false positive gets handled by hand or dismissed with a reason.
2. Diff per alert, not per PR. Check out the branch and walk through it file by file: gh pr checkout 123, then git diff origin/main...HEAD --stat to see the spread, then the full diff per file.
3. Look for behaviour changes on valid input. Security fixes often tighten input handling: a path check that now rejects filenames with spaces, an escaping change that double-encodes text already escaped elsewhere, a stricter regex that refuses real customer data. Ask, for each change, what valid input could now behave differently.
4. Check the fix is in the right layer. A sanitiser added at one call site leaves the other callers exposed; a fix inside a shared helper changes every caller. Both may close the alert.
5. Look for suppressions dressed as fixes. A new comment, a dropped code path or a removed test can make an alert disappear. None of those is a fix.
6. Run your tests, and add one. Each fix should come with a test for the case the alert describes. If the agent did not write one, ask for it in a PR comment.
7. Split if needed. If two of 25 fixes are wrong, ask Copilot to drop them, or revert those files, and merge the rest. A batch does not have to be all or nothing.

A trial plan for one afternoon

1. Set the Code Security AI-credit budget.
2. Run the gh query and pick one rule with five to ten instances in tested code.
3. Assign those alerts to Copilot in one batch.
4. Review the draft PR with the checklist and note, per fix: merged as is, edited, or rejected.
5. The next day, read the AI-usage and Actions numbers for that one session.

After that you have three numbers that matter for your repo: the share of fixes you merged unchanged, the review time per fix, and the cost of the session. Those tell you whether to point it at the next 25, not the changelog.

Sources

• GitHub Changelog: Agentic autofix for code scanning alerts is generally available (October 15, 2026)
• GitHub Docs: Resolving code scanning alerts (assigning alerts to Copilot)
• GitHub REST API: Code scanning alerts