// answer

Can GitHub code scanning auto-fix alerts by opening a pull request for review?

Short answer

Yes. GitHub Copilot Autofix can generate a fix and open a draft pull request for review, but it is best-effort, not guaranteed, and still needs a human to review and merge.

If you want to ask a follow-up rather than read one: Join a community

Can GitHub code scanning auto-fix alerts by opening a pull request for review

Yes. GitHub Copilot Autofix can generate a fix for a code scanning alert and open a draft pull request for review. GitHub also says the feature is best-effort, so the PR is a starting point, not a finished answer.

Code scanning and Autofix solve different problems. Code scanning finds the alert. Autofix proposes a change. The pull request gives you a place to inspect the patch, run checks, comment on the result, and decide whether to keep it.

GitHub documents two related flows. In the pull request flow, code scanning can post a review with annotations on the offending lines, and Copilot Autofix can suggest fixes directly in that pull request. In the alert flow, GitHub can also generate an autofix from the repository’s default branch and, when you choose to commit it, create a pull request with the suggested fix.

The important part people get wrong is this: code scanning does not silently repair code on its own. A fix suggestion may appear inside the pull request, or GitHub may create a draft pull request for the alert, but a person still has to review it and accept the change. GitHub says Copilot Autofix will not generate a fix for every alert in every situation.

The inconvenient part is that the pull request can still be wrong even when it looks plausible. GitHub says the system uses repository code, pull request context, and analysis data to build the suggestion, but it also says validation is best-effort. If the fix is incomplete, inaccurate, or based on a false positive, you still need to reject or edit it before merging.

If you are working inside a pull request, the normal workflow is simple: review the alert annotation, inspect the suggested autofix, and apply it only if the code change makes sense. If you commit a change to that pull request, GitHub runs the checks again. If the fix really addresses the issue, the alert closes and the annotation disappears.

If you are working from the alert page, GitHub can generate a suggested fix and show a Create PR with fix action when Autofix is available. GitHub’s REST API also exposes endpoints to create an autofix and commit an autofix for a code scanning alert. That means the automation can produce a branch or PR, but it does not replace review or testing.

The practical answer is yes, GitHub code scanning can open a pull request for review through Copilot Autofix. The safer reading is narrower: it can propose and package a fix, then hand it to you for review. The human step is still part of the design, because the output is a suggestion, not an authority.

If you want the operational details for your own workflow, start from the alert in the Security and quality tab, generate the fix, then inspect the draft PR line by line. If the fix looks good, merge it like any other change. If it does not, treat it like any other bad suggestion and rewrite it before it reaches default branch.

For teams that already run code scanning on pull requests, this is useful because the fix stays close to the alert and can be reviewed in context. For teams that expect a one-click repair, it is inconvenient by design: the system surfaces the problem, proposes a patch, and leaves accountability with the reviewer. That is the part that keeps it usable.

If you need to trace the feature in your own docs, GitHub describes Autofix in the code scanning alert docs, the pull request triage docs, the AI features responsibility page, and the REST API reference. Those pages line up on the same point: Autofix can generate and commit a fix, and the resulting pull request still needs review before merge.

If your goal is to ship a fix faster, Autofix helps with the first draft. If your goal is to remove review, it does not do that. The pull request is the checkpoint, not the shortcut.

What usually happens in practice

A developer opens a pull request, code scanning flags a vulnerability, and GitHub shows an autofix suggestion on the alert. The reviewer checks the diff, applies the suggestion if it is sound, then lets the checks rerun. If the suggestion changes the wrong file, misses a related sink, or shifts behavior, the reviewer edits the PR instead of trusting the automation.

What happens when it goes wrong

If Autofix cannot generate a fix, GitHub says so. If it thinks the alert may be a false positive, it can say that too. In both cases, the result is still a code scanning alert, and someone has to decide whether to dismiss it, repair the code manually, or ask for a different fix.

Best mental model

Treat Autofix as a reviewer helper that can open or update a pull request, not as an autonomous maintainer. It reduces the time from alert to patch, but it does not remove the need to understand the code.

Related workflow for teams

If your repository uses branch protection or requires resolved conversations, code scanning annotations fit naturally into that process. The autofix can be part of the same review cycle, but it does not bypass the merge rules you already rely on.

For DevConnect context and workflow planning, you can keep your own testing exchange rules on your side of the process at https://devconnectplatform.com, while GitHub handles the code scanning side.

FAQ

Does GitHub code scanning always create a pull request automatically No. GitHub can generate an autofix and, in some flows, create a draft pull request, but it does not do that for every alert and it is not guaranteed to succeed.

Can I use Autofix on alerts in existing pull requests Yes. GitHub shows code scanning alerts inside pull requests and can display Copilot Autofix suggestions there, so you can review and apply the fix in context.

Do I still need to review the suggested fix Yes. GitHub describes Autofix as best-effort, which means the suggested patch still needs human review before merge.

Can I automate this through the API Yes. GitHub provides code scanning API endpoints to create an autofix, get its status, and commit an autofix for a code scanning alert.

Will every alert get a useful autofix No. GitHub says Autofix will not be able to generate a fix for every alert in every situation, so manual remediation is still part of the workflow.

Frequently asked questions

Does GitHub code scanning always create a pull request automatically

No. GitHub can generate an autofix and, in some flows, create a draft pull request, but it does not do that for every alert and it is not guaranteed to succeed.

Can I use Autofix on alerts in existing pull requests

Yes. GitHub shows code scanning alerts inside pull requests and can display Copilot Autofix suggestions there, so you can review and apply the fix in context.

Do I still need to review the suggested fix

Yes. GitHub describes Autofix as best-effort, which means the suggested patch still needs human review before merge.

Can I automate this through the API

Yes. GitHub provides code scanning API endpoints to create an autofix, get its status, and commit an autofix for a code scanning alert.

Will every alert get a useful autofix

No. GitHub says Autofix will not be able to generate a fix for every alert in every situation, so manual remediation is still part of the workflow.

Know someone stuck on this? Send them the answer.

Sources

Every link here was fetched and confirmed to resolve before this page went live.

More on this topic: Open source

Related questions

Not the question you had?

Ask it. Every source gets fetched and checked before anything goes up, so it takes a day or two, and questions that cannot be answered honestly do not get a page at all.

No account, no email address needed.

Where developers talk about this

DevConnect has communities for the things this page covers. Smaller than the big forums, and nobody is farming engagement.