Copilot Memory now stores your security fix patterns

Your security remediations just became training context. GitHub shipped a changelog entry wiring agentic autofix into Copilot Memory: when the agent fixes a security alert, it first checks existing memories for context, then stores the fix pattern as a new memory for next time. Both features are in public preview. If you run Copilot on a private repo, this is a data-flow change worth ten minutes of your attention.

What actually happened

The mechanics are two-way. Before autofix proposes a remediation, it reviews memories already stored for that repository to pick up context. After a fix lands, it writes the fix pattern back as a memory. GitHub's framing is that those stored patterns go on to resolve additional alerts and teach other Copilot surfaces — code review, the cloud agent — the "secure development patterns unique to your repository."

Copilot Memory itself is the part to understand. Per GitHub's docs, it stores two things: repository-level facts discovered through interactions with Copilot coding agent, code review and the CLI, and user-level preferences scoped to a single person across repos. Memories are repository-specific, validated against the current codebase before use, shared across Copilot features, and automatically expire after 28 days so stale facts age out.

Governance exists and is reasonably placed. Repository owners can review and delete stored memories under Repository Settings → Copilot → Memory. Copilot Memory is in public preview for all paid Copilot plans, and GitHub turned it on by default for Pro and Pro+ users back in March.

The changelog says the autofix integration applies to "customers who've enabled it," which reads as opt-in at the feature level — but with Memory already defaulted on for some plan tiers, "enabled" is not the same as "chosen." Go look rather than assume.

Why a memory layer changes your AppSec review

A security fix pattern is a description of your weakness. "This repo handles auth this way and the fix for that class of bug is this" is a useful memory and also a concise map of where you were vulnerable. It is now stored server-side, outside your repo, on a preview feature. That is not a scandal — it is a data-classification question that somebody on your side should answer on purpose.

28-day expiry is a design choice, not a compliance answer. It is good engineering: stale memories about deleted code are worse than no memories. But if you are under a retention or data-residency obligation, "expires in 28 days" is a fact you have to be able to state and evidence, not one you assume. Check the setting, screenshot it, file it.

Default-on is the part to check today. Memory landed on by default for Pro and Pro+ in public preview. Most teams we talk to have no idea which Copilot previews are live in their org. Open Repository Settings → Copilot → Memory on your most sensitive repo and look at what is actually stored. Ten minutes.

The upside is real, and it is consistency. The reason we keep telling clients to write down their conventions is that agents and juniors both guess when you do not. A remediation pattern that carries from one alert to the next is exactly the leverage you want — an agent that fixes the second SQL injection the way you fixed the first one. The catch is that you should be able to read what it learned.

Treat autofix output as a proposal, always. An agent that has memorized your fix pattern will apply it confidently, including to the case where it does not fit. Reviewing a security patch is not the step to automate away.

Sources: GitHub Changelog: Agentic autofix now uses Copilot Memory, GitHub Docs: About GitHub Copilot Memory.