GitHub made agentic autofix generally available on October 15, 2026. Assign an alert to Copilot and it can investigate the repository, propose a repair, rerun CodeQL, and open a draft pull request with its validation summary. For application-security teams, the review question is whether that rerun examined the condition that produced the original alert.
GitHub's autofix documentation gives a specific limit: the agent reruns the code-scanning query suite. It cannot confirm fixes for custom CodeQL queries, the security-extended suite, or third-party scanner alerts. Those findings need validation through their original configuration.
Start with the alert's scanner, rule, and analysis configuration. Match fresh results to the code under review, then check the default branch again after merge. The procedure below is our engineering recommendation based on GitHub's documentation; we have not run an agentic autofix session or measured its repair accuracy.
Set the rollout scope before assigning alerts#
The GA announcement covers GitHub Code Security and GitHub Advanced Security customers on Enterprise Cloud, including data residency. This guide focuses on organization-owned repositories in that deployment.
GitHub's access instructions separate enterprise permission from enablement. Enterprise policy allows organizations to configure the feature; an organization owner or security manager enables it for eligible repositories. Repository administrators can opt out. Organizations that used the public preview must enable it again. Coordinate repository exclusions before enabling the organization setting.
Each assignment consumes AI credits and Actions minutes. Keep a reviewer responsible for the resulting PR and preserve the repository's coding-agent execution controls. Decide whether Copilot approvals may count separately from whether Copilot may propose a fix.
Under GitHub's assignment procedure, the alert must exist on the default branch. A finding confined to a release branch or PR needs another remediation path. Start with one alert so its original evidence and proposed repair are easy to compare.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Preserve what raised the alert#
Before assignment, save the alert URL and number, rule ID, scanner name and version, affected branch, and source revision. Keep the workflow and scanner configuration used by that run, including query packs, exclusions, and build settings. These records establish what you expect the repair to pass.
For example, suppose an internal CodeQL query reports that a document-download handler skips a tenant check. Copilot changes the handler and its built-in rerun passes. That is a hypothetical review case, not a result we observed. The custom query still needs to run against the changed code, and the service owner still needs to check that legitimate downloads work and access remains limited to the right tenant.
Open Affected branches on the alert page and select the relevant branch. GitHub's configuration view lists the configurations that generated the alert and their update times. One alert can have several analysis origins. Record each one that remains part of your required coverage.
Do not change the scanner setup just to obtain a passing result. GitHub documents that enabling default setup disables the existing CodeQL workflow and blocks CodeQL API uploads. If the repository relies on a custom workflow, that switch can remove the validation you intended to preserve.
Collect the branch and analysis evidence#
The following read-only commands use an already authenticated GitHub CLI. Run them in a new evidence directory, replacing the placeholder identifiers. The API calls need access to the repository's code-scanning results; supported fine-grained tokens use Code scanning alerts: read. Keep the output in your approved security evidence store.
Before assignment, save the original alert:
Code source: GitHub code-scanning REST endpoints, adapted for GitHub CLI.
set -euo pipefail
repo='OWNER/REPO'
alert_number='ALERT_NUMBER'
gh api --method GET \
-H 'Accept: application/vnd.github+json' \
-H 'X-GitHub-Api-Version: 2026-03-10' \
"repos/$repo/code-scanning/alerts/$alert_number" \
> original-alert.json
After the repair PR's validation completes, collect the alert instances and PR analyses in the same shell. These exports need a reviewer to interpret them.
Code source: GitHub code-scanning REST endpoints, adapted for GitHub CLI.
pr_number='PULL_NUMBER'
gh api --method GET --paginate \
-H 'Accept: application/vnd.github+json' \
-H 'X-GitHub-Api-Version: 2026-03-10' \
"repos/$repo/code-scanning/alerts/$alert_number/instances" \
-f per_page=100 \
--jq '.[] | {ref, commit_sha, analysis_key, category,
environment, state}' > alert-instances.ndjson
gh api --method GET --paginate \
-H 'Accept: application/vnd.github+json' \
-H 'X-GitHub-Api-Version: 2026-03-10' \
"repos/$repo/code-scanning/analyses" \
-f per_page=100 -f pr="$pr_number" \
--jq '.[] | {id, ref, commit_sha, analysis_key, category,
environment, tool, created_at, error, warning,
rules_count, results_count}' > pr-analyses.ndjson
Preserve later snapshots separately. The API exposes reference, revision, configuration identity, tool, and diagnostic fields. Those fields alone do not establish which exact query-pack revision executed. Retain the associated workflow logs and configuration alongside them.
An empty export means you have no matching evidence from that request. An API error means collection failed. Neither establishes that the vulnerability is gone. If the original scanner does not upload results to GitHub, collect its native report and job metadata instead.
Match the result to the code being reviewed#
Inspect the PR's current head and base revisions and the source checkout used by the analysis job. A PR scan may analyze refs/pull/<number>/merge, GitHub's test merge of the proposed change with its base. Its SHA can legitimately differ from the PR head. Preserve that relationship using the run's checkout metadata; a head-SHA-only comparison would reject valid merge-ref evidence. GitHub documents the distinction in PR scanning configuration.
If either side changes after the analysis, obtain results for the new proposed merge. The result must cover the code you intend to merge, however recently the scanner ran. Repositories using a merge queue also need the documented merge_group trigger so code scanning runs for the queued merge.
Compare the scanner and configuration with the original finding. Matching analysis_key, category, and environment helps identify the analysis origin, but a workflow can keep those labels while changing its queries or exclusions. Review changes to the workflow, query configuration, and affected source paths. For a custom query, retain evidence that the query actually ran.
Use the following decisions during review. They are recommendations derived from GitHub's configuration behavior and PR check behavior.
| Evidence found | Decision before accepting validation |
|---|---|
| Built-in CodeQL passes; original finding came from a custom query | Run the original query configuration against the proposed repair. |
| Correct scanner ran, but against an earlier revision | Repeat validation for the current proposed merge. |
| Matching analysis reports an error or coverage warning | Read the logs and resolve the missing coverage before counting that analysis. |
| PR check succeeds but the original alert still appears in branch results | Inspect the finding itself; a severity threshold can permit a successful check with alerts. |
| One configuration reports fixed and another has an old timestamp | Rerun the required configuration or document its deliberate retirement. |
| No matching analysis or instance can be found | Keep validation unresolved and obtain the original scanner's report. |
The PR's inline annotations are also incomplete as a review surface: they cover findings on changed lines. Use View all branch alerts in the code-scanning results to inspect the broader result set. A patch that moves the relevant code outside the diff still needs review.
Have an engineer inspect the changed data flow and run the project's functional and security regression tests in its approved environment. Check for removed checks, broadened exceptions, and query suppressions that could explain a disappearing finding. Scanner closure supports this review but cannot establish every application invariant.
Confirm closure on the default branch#
Before merge, the default-branch alert may correctly remain open while the PR analysis shows a fix. After the approved merge, verify that the original scanner configuration completed on the resulting default-branch revision and inspect the affected alert instances again. Preserve the PR evidence and the post-merge evidence as separate records.
GitHub's alert-resolution documentation distinguishes a code fix from dismissal. Dismissal removes the alert from the active count across branches and records a reason. Treat a dismissal as a separate triage decision, with its own justification, rather than evidence that the agent repaired the code.
For the hypothetical tenant-check finding, the completed review should identify the custom rule, the analyzed revision, the unchanged or deliberately reviewed scanner configuration, the regression-test result, and the reviewer. If a required configuration is missing, leave that gap explicit. If a configuration has been retired, record why and which assessment replaces it before cleaning up its stale alerts.
Keep the remediation open until the required evidence arrives, or record the named owner's decision to accept the remaining risk.
Frequently asked questions
- Does agentic autofix validate custom CodeQL queries?
GitHub says its built-in validation reruns the code-scanning query suite and cannot confirm fixes for custom queries, security-extended queries, or third-party scanner alerts. Run the original configuration separately and inspect its results.
- Why can an alert remain open after an autofix PR passes?
The alert page may still reflect the default branch, another configuration may be stale, or the original scanner may not have analyzed the fix. Check Affected branches, configuration timestamps, and the analyzed revision before deciding that the patch failed.
- Does a successful code-scanning check mean no alerts remain?
No. GitHub's check result depends on configured severity thresholds, and PR annotations cover changed lines. Review the original finding in the full branch results and confirm which scanner configuration ran.
