Agentic autofix with Copilot Memory: fixes that learn

Agentic autofix now reads your repository's stored memories before it proposes a security fix, and writes the successful fix back as a memory for next time. GitHub announced it on 25 September 2026. That closes a loop, and it also changes what a reviewer is actually approving: a patch that matches your codebase's habits is not the same thing as a patch that is correct.

The short version of what changed:

• When you use agentic autofix, it reviews existing memories for context that can help resolve a security alert.
• When it creates a fix, it stores the fix pattern as a memory for future use.
• Those memories can help resolve additional alerts and teach other Copilot features, GitHub naming Copilot code review and Copilot cloud agent.
• Both agentic autofix and Copilot Memory are in public preview, and Memory must be enabled.

What agentic autofix with memory actually does

Copilot Memory is not a general context window. GitHub's documentation describes two kinds of memory: repository-level facts — coding conventions, architectural decisions, build commands, project-specific rules — and user-level preferences about how an individual wants to work with Copilot. Repository facts are visible to anyone with access to Memory in that repository. User preferences stay with the user.

Three constraints in that documentation matter more than the headline. Repository facts are stored with citations pointing to the code that supports them, and Copilot re-checks those citations against the current branch before use, so only validated facts are applied. Facts are created only by users with write access who have Memory enabled. And anything stored but unused is deleted after 28 days, with the timer resetting when an entry is validated and used.

Enablement is per user, not per repository. On individual plans it is on by default; on organization- and enterprise-managed plans an administrator enables the policy first and individual users can then opt out. GitHub also notes that facts can be captured from pull requests that were closed without merging — the validation step is what stops a rejected approach from surviving as a rule.

Why a fix that matches your patterns is not a fix that is correct

This is our argument, not GitHub's. Memory optimises for consistency with what your repository already does. Security review asks a different question: does this change remove the vulnerability without changing what the program means. Those two questions agree most of the time, and the interesting cases are the ones where they do not.

The failure mode worth naming is a bad pattern promoted to a standard. If the first autofix in a repository sanitises input in a way that happens to pass CodeQL but leaves an encoding edge case open, that shape is now stored as the fix pattern and is available to the next alert, to Copilot code review and to the cloud agent. One under-reviewed merge becomes the house style. Nothing in the mechanism distinguishes a pattern that worked from a pattern that was merely accepted.

GitHub's own responsible-use documentation is candid about the underlying limits, and it is worth quoting to your team rather than paraphrasing. It lists semantic errors — suggestions that are syntactically valid but change program semantics, because "the system has no understanding of the programmer's intent" — along with location errors, partial fixes, and fixes that "fail to remediate the underlying vulnerability or introduce new vulnerabilities". It warns that suggested dependency changes may include fabricated packages "published under statistically probable names". And it states plainly that you must always review suggestions and edit them as needed before accepting. Memory does not retire any of those warnings; it makes the confident-looking ones more frequent.

Can I trust an AI security fix?

Trust the diff, not the provenance. In the systems we build, the checks that catch the difference between a matching fix and a correct one are boringly specific:

• Read the alert, then the patch, in that order. Confirm the change addresses the data flow CodeQL flagged, not a nearby symptom. A closed alert is not evidence; autofix output is tested against the alert, which is exactly what a partial fix can satisfy.
• Look for the behaviour change. GitHub's guidance is that good test coverage is what verifies a fix has not altered the codebase's behaviour. If the touched path has no test, write one before merging rather than after.
• Check every dependency line. Any added or bumped package gets verified against the registry by hand, given GitHub's own warning about plausible-sounding fabricated names.
• Ask where the pattern came from. If the fix mirrors an existing convention, go and look at the original. You are now approving that convention for every future alert, not just this pull request.
• Verify CI passes and the alert is resolved before merge, which is GitHub's stated instruction and the one most often skipped when a bot opens the pull request.

The review economics here are the same ones we wrote about in AI code review automation and auto-approval: generation gets cheap, verification does not, and the queue moves to review. Memory makes generation cheaper again. It does nothing for the other side.

Who should turn it on, and who should wait

Turn it on if you have real test coverage on the paths CodeQL tends to flag, a security reviewer who reads diffs rather than statuses, and someone who will audit stored repository facts. Repository owners can review and manually delete the facts stored for their repository, and that is the control that makes the feature safe rather than merely convenient. Put it in someone's calendar; an unaudited memory store is a style guide nobody wrote.

Wait if your repository is in the state most alert backlogs are actually in. Where nobody is triaging, autofix with memory will generate plausible fixes faster than anyone can evaluate them, and the backlog becomes a merge queue instead of an alert queue. That is a worse problem, not a smaller one — we made the same argument about what to automate and what to keep in vulnerability triage.

Also wait if your confidence rests on the tests passing. A fix that satisfies your suite while quietly changing semantics is precisely what a suite with high line coverage and low assertion quality will wave through, which is the gap between coverage and mutation testing. And remember that both features are public preview: GitHub reserves the right to change behaviour, so do not build a compliance process on this as of September 2026.

The strongest case for the feature is the one GitHub makes: a codebase has conventions, and a reviewer who learns them produces better work over time, so a tool that learns them should too. That is true. The difference is that a human reviewer who learns the wrong convention can be told, in a conversation, that it was wrong. A memory store has to be found and deleted.

The practical next step is smaller than a policy decision. Open the last three merged autofix pull requests in your busiest repository and check whether anyone actually read the diff, or whether the green tick was the review. That answer tells you whether to enable memory now or fix your review path first. If review capacity is the real constraint, that is a QA and automation problem before it is a Copilot one.