Autofix that reads more than one file: GitHub previews agentic code scanning fixes

When "Fix" used to mean "patch this one line"

I remember the first time an autofix suggestion landed in a PR of mine and felt slightly haunted. The tool had spotted a vulnerable pattern in one file, wrote a clean patch for that line, and left every other call site of the same function alone. The fix was correct. It was also incomplete, and I only noticed because I had grepped for the function name out of habit. The rest of the codebase was quietly waiting for someone to remember.

That small ambient friction is what GitHub is trying to knock a corner off. On July 10, 2026, the GitHub Changelog announced that agentic autofix for code scanning alerts is in public preview. The behaviour, per the changelog: the autofix explores relevant files and proposes a fix across the codebase, the way a developer would.

If you have ever hunted the second instance of a bug that the linter only flagged in one place, that sentence lands.

What the preview actually does

The primitive is straightforward. When code scanning raises an alert, the autofix opens a session that reaches beyond the file that triggered the finding. It walks into the files related to the alert, works out what a matching change looks like there, and returns a single proposed fix that touches all of them.

You still get a PR-shaped artifact at the end. What changes is where that artifact came from. The scope moved from "the line" to "the codebase around the line".

Where you will feel this on your next scan

For the engineer waiting on the pipeline, the concrete DX shift is this: fewer follow-up PRs, and fewer alerts that come back a week later because a second call site was missed. The class of finding this helps most is the one that shows up in the same shape in ten places, where the fix is mechanical and identical each time. Bumping an unsafe API to its safe cousin. Moving a template render behind an escape helper. Catching the ignored error return on a helper that fifteen other files call. Those cases were the ones that made the older single-file autofix feel like a demo, and this is where the "how a developer would do it" framing earns its keep.

For a platform engineer, there is a new shape of CI gate to reason about. A code scanning alert is now a small change budget an agent can spend across your repo. That is a different animal from an inline suggestion. The blast radius of the fix moved from lines to modules, and that shift belongs in your threat model.

Guardrails worth setting before you flip it on

A few things I would set up before letting the multi-file version touch anything important.

Keep autofix suggestions arriving as PRs, not direct commits, so the diff still lives in review and CI. If your required checks already gate merges, that is your seatbelt. Look at the branch protections around your code scanning workflow, and confirm that a proposed fix cannot bypass the same tests a human PR runs.

Turn on CODEOWNERS on the paths where an autofix should never be the final word. Anything with cryptography, auth, session handling or license-sensitive code deserves an explicit human reviewer on the door. That is the same rule you apply to any contributor who is new to that file, and an agent should not get a shorter path.

Watch the number of files a single fix touches. A three-file autofix on a routing helper is friendly. A twenty-file autofix on a security-adjacent module is a signal to slow down and read the diff twice.

What I am watching next

The bit I want to see land is a reasoning trail. Reviewers will want to know why the agent decided these files were relevant, not just what it changed. A one-line summary of "why these files" would be enough for me to trust the change in a lunchtime review pass. Without it, review load moves from "read the fix" to "audit the file selection", and that is not the trade I want.

The other thing worth watching is what happens in a large, sprawling monorepo, where "relevant" is a fuzzy word. Multi-file autofix in a service with three tidy directories is one problem. Multi-file autofix in a repo where domain boundaries are aspirational is another. If you turn this preview on in a real one before I do, I would genuinely like to hear how it went.