GitHub agentic autofix reaches GA: what should you review after the draft PR?

What changed on October 15?

The GitHub GA announcement, dated October 15, 2026, describes an Enterprise Cloud entry for Code Security / Advanced Security customers. Copilot investigates assigned default-branch alerts and delivers a draft PR after validation. Up to 25 alerts can share a PR; findings detected only on a PR or another branch cannot be assigned through this workflow.

This is a separate decision from the previous day’s HydraFusion preview changes. Here, the question is how to receive a security fix with adequate evidence. The pilot and acceptance example below are editorial recommendations, rather than results from your repository.

Check repository eligibility and existing controls

The current official documentation distinguishes agentic autofix from Copilot Autofix and also discusses eligible personal public repositories. Ownership and higher-level policies matter. It records AI-credit and Actions-minute consumption and limits on validation for custom or third-party findings. Do not infer this feature’s availability from ordinary Copilot Autofix access.

Ask an existing administrator to verify the applicable repository entry, policies and billing setup before a pilot. This article does not estimate prices or recommend changing organization permissions to try a feature. If the control is absent, record the repository type and restriction, then consult the relevant management instructions.

Choose one finding with understandable behavior

Select a default-branch finding that maintainers have confirmed needs attention. Record its link, affected location, baseline commit and relevant tests. Avoid combining unrelated findings in the first assignment. A maximum of 25 in the announcement is a capacity limit, rather than a recommended batch size.

For an original fictional example, imagine a file-reading feature requiring input validation. Define two expectations before reviewing a patch: a valid file still opens, and empty input receives a clear error. This describes acceptance planning, not a detected vulnerability or successful repair. Reviewers need an explanation of both the changed risk and the behavior that should remain usable.

Finding link and baseline commit: ____
Candidate PR and affected files: ____
How the change addresses the finding: ____
CodeQL evidence and uncovered scope: ____
Expected and observed valid-input / empty-input behavior: ____
Unresolved questions for maintainers: ____

Separate scan evidence from functional acceptance

Read the complete diff and explanation first. In the fictional example, ask whether valid file requests still follow the intended route, whether empty input produces the expected message, and whether new validation rejects legitimate use. A short diff or polished explanation cannot establish those outcomes.

Then reconcile the scan’s commit, execution status and result with the current patch. Record which checks ran and what remains uncovered. A passing query supports a particular check on a particular version; it does not certify the entire application. Maintainers must select additional regression cases from their real product requirements.

Give legitimate behavior a contract before judging the patch

Extend the file-reading scenario with a complete filename acceptance exercise. It touches no filesystem and describes no real vulnerability repair. The fictional application accepts one basename: .txt and .csv are supported, extensions are case-sensitive, and accented characters are allowed. Reject an empty string, ordinary spaces alone, and any input containing a forward slash or backslash. Unlisted extensions remain unsupported rather than being silently added.

A candidate patch allowing only English letters, digits and .txt may reject some invalid input while also blocking the permitted report.csv and résumé.txt. Demonstrating that empty input is rejected will not expose that regression. Write the expectations independently of the patch, then compare each candidate result with them.

What sits between a clean scan and a merge decision?

Consider two constructed review situations. In A, the scan belongs to baseline B0 while the patch has reached C1; an older green result does not answer C1’s status. In B, the scan does correspond to C1, but the implementation rejects report.csv. Scan evidence and a functional failure can coexist. B0, C1 and these outcomes are teaching assumptions, not records from an actual repository.

For B, give the author the failing input, expectation and observed result, then request another run after preserving the supported formats. Do not delete a failing test to obtain a merge label. These filename rules are not a complete security repair either: actual file access can involve resolved locations, symbolic links, concurrent state and platform differences. Maintainers need system-specific checks for those concerns.

The official Autofix documentation requires reviewing and testing generated changes before merging. For a broader multi-model maintenance proposal, continue with the HydraFusion duplicate-request exercise, without transferring another tool’s or scan’s pass to the current patch.

Decide whether to expand from observed evidence

After the pilot, record manual revisions, verification blockers and actual usage before expanding to similar findings. Without observed data, do not claim a percentage improvement or a measured reduction in repair time. Repeatedly explaining why a fix is acceptable is more useful than counting generated PRs.

Keep a candidate in draft if it touches unclear business rules, cannot run necessary validation or produces inconsistent results. Bring those blockers to maintainers. The Copilot review access and billing checklist can help organize questions about existing processes, while this feature’s own documentation remains the source for its eligibility.