GitHub Copilot Memory Expires Facts After 28 Days, Unless They Keep Getting Used
What the Copilot Memory docs actually promise about retention, scope, and who can read the facts an agent writes about your repository
Copilot Memory has a garbage collector, and it runs on popularity.
GitHub's documentation puts it in one sentence: "Any stored fact or preference that goes unused is automatically deleted after 28 days." Read the inverse. A fact that does get used does not get deleted, and the docs say the timer resets when Copilot validates and uses the entry. Which means the memories that survive longest in your repository are, by construction, the ones the agent reaches for most often. Not the ones that are most correct. The two usually overlap. The interesting failures live in the gap.
This matters more since September 25, 2026, when GitHub wired Copilot Memory into agentic autofix. Autofix now reviews existing memories for context on a security alert, and when it produces a working fix it stores that fix pattern as a memory for later use. A security remediation tool started writing down what it learned, in a store that keeps whatever gets reused.
The part the changelog left out, and the docs did not
The September 25 changelog says almost nothing about the storage layer. It names no retention period and no scope. That reads like an oversight until you go to the Copilot Memory concept docs, where all of it is written down plainly, and where the mechanics are more specific than most agent-memory products bother to be.
Memories come in two scopes. Repository-level facts cover "coding conventions, architectural decisions, build commands, and project-specific rules," and they are available to every user with Copilot Memory access to that repository. User-level facts cover "implied or stated personal preferences about how a user wants to interact with Copilot," and they follow that one user across repositories. The docs close the obvious worry directly: repository facts "can only be used in operations on the same repository." Nothing you fix in a private service leaks into a public one through this path.
So the cross-repository leak is not the story. The story is what happens inside one repository, over months, to a fact nobody reviewed.
Four Copilot surfaces read this store. The docs list "Copilot cloud agent, Copilot code review, Copilot CLI, and agentic autofix," with one carve-out worth noting: "Copilot code review uses repository-level facts only. User-level preferences are not applied during code review." A fact written by autofix while patching an alert is therefore a fact your code reviewer consults on unrelated pull requests, and it arrives with no citation back to the incident that produced it.
Why a self-resetting TTL is a different animal
Most retention policies are a clock. You write something, and in N days it goes away whether or not anyone cared. That model is boring and safe, because it bounds the lifetime of a mistake.
Copilot Memory is not that. It is a least-recently-used cache with a 28-day floor, and LRU eviction has a well-understood property: it preserves whatever the workload touches, and the workload is not an oracle. If autofix writes "this service validates JWTs in the gateway, not in the handler" while fixing an alert, and that fact happens to be true of three handlers and false of the fourth, it will be retrieved constantly, validated against the three, and kept forever. The fourth handler is the one you will read about in a postmortem.
I have watched the same shape play out in retrieval systems that had nothing to do with agents. A cached assumption that is right 90% of the time gets more reinforcement than a cached assumption that is right 100% of the time but rarely relevant. Frequency of use is a proxy for correctness, and it is a poor one in exactly the cases that hurt.
The security context sharpens it. Alert remediation is a domain where the fix that worked and the fix that was correct are not always the same fix. Suppressing a finding, adding a null check where the real problem was an unvalidated boundary, pinning a dependency instead of understanding why the call was reachable. Those all read as successes to the tool that shipped them, and under this retention rule a fix pattern distilled from them persists as long as it keeps being useful.
Who can actually see and remove these
This is where the docs earn some credit, because the controls are real and reasonably granular.
Repository owners can review and delete repository-level facts. Individual users manage their own preferences. On Copilot Business and Enterprise, the docs state that "user-level preferences can also be exported or deleted by an organization or enterprise administrator, either in bulk or per user." And there is an audit trail: "Events appear in your organization or enterprise's audit log when an administrator exports or deletes memories, and when a user opts out of Copilot Memory."
Note what that audit log covers. Exports, deletions, opt-outs. Administrative actions on the store. It is not a log of what got written, which is the event you would most want when reconstructing why the agent believed something.
The default state depends on which GitHub you are. The administrator guide scopes its default to managed subscriptions: "For enterprise- and organization-managed Copilot subscriptions, Copilot Memory is off by default and must be enabled in the enterprise or organization settings." Then the second half of the rule, in its own sentence: "Once Copilot Memory is enabled, the feature is on for users by default." Individuals are in a different position: since March 4, 2026, Copilot Memory has been "on by default for individual users on Copilot Pro and Copilot Pro+ plans," with opt-out under Features > Copilot Memory in personal settings. So the September changelog's framing of "customers who've enabled it" is accurate for a company and misleading for a solo developer on Pro, who has probably been accumulating memories for six months.
Put this into practice
The lowest-friction first step costs you one browser tab. Go read your repository-level facts. If Memory is on in your organization, those facts already exist, and nobody on your team has looked at them. Repository owners have the review-and-delete surface; open it and read the list top to bottom. Most of what you find will be dull and correct, which is the point: you need the baseline before a bad entry means anything.
Then do the deliberate version. Pick a repository you can afford to be wrong in, enable Memory if it is off, and let agentic autofix close two or three real alerts. Come back a week later and read what it wrote. You are looking for one specific class of entry: a fact stated more generally than the evidence supported. "The auth middleware handles input validation" is the dangerous shape. "The auth middleware in gateway/mw.go validates the sub claim" is the safe one. The difference is whether a future retrieval can over-apply it.
Third, build the review into something that already happens. A quarterly repository-facts read is a calendar event nobody honors. A line in your pull-request template asking whether this change invalidates a stored repository fact is friction in the right place, because the moment you change the architectural decision is the moment the fact about it goes stale. Nothing in Copilot Memory notices that your refactor made a stored fact false. The 28-day timer will not help you, because the fact is still being used.
Fourth, if you administer this at an organization, turn on the audit-log alerting you have for other Copilot events and accept that it covers exports, deletions and opt-outs rather than writes. Then decide, explicitly, whether repository facts written by autofix should be readable by code review. You cannot configure that split today. You can at least know it exists before someone asks you in an incident review.
And if you are on Pro or Pro+ and have never opened Features > Copilot Memory, open it. Not because you should turn it off, but because you have six months of stored preferences you have never read.
Honest limitations
I have not run agentic autofix with Memory enabled and watched what it writes. Everything above about the write path is read out of GitHub's documentation and changelogs, not observed, and documentation describes intent rather than behavior. If autofix writes narrow, well-scoped facts in practice, the failure mode I am describing is theoretical.
The docs do not state a capacity limit, and I could not find one. So I do not know what happens when a repository accumulates more facts than the retrieval step can use, or whether that eviction is also usage-ranked. If it is, the concern compounds; if there is a hard cap with different semantics, some of this changes.
I also cannot see the retrieval mechanism. "Goes unused" implies a definition of use that I do not have: retrieved-and-included, retrieved-and-cited, or something narrower like the docs' phrase about Copilot validating the entry. That distinction decides how easy it is for a fact to keep its timer alive, and it is the single most load-bearing unknown in this piece. The docs say the timer may reset when Copilot "successfully validates and uses" an entry, which suggests something more selective than a bare retrieval, and that would cut against my argument. I am naming it rather than smoothing it over.
Nothing here is a vulnerability, and GitHub published no advisory. The mechanism is documented, the controls exist, and an administrator who reads the docs can reason about it. My claim is narrower: the retention rule creates a durability asymmetry that favors frequently-used facts over correct ones, and the write event is the one thing the audit log does not record.
Finally, the 28-day figure and the scope rules are what the docs say as of September 26, 2026. Public-preview products change their retention semantics, and this one is in public preview on both halves.
Where that leaves you
Agent memory is going to be table stakes, and GitHub's version is better documented than most. The thing worth carrying forward is not a verdict on the feature. It is a habit: when a vendor tells you how long memories last, ask what resets the clock. A fixed TTL bounds your exposure to a wrong fact. A usage-reset TTL does the opposite, and it leaves no trace while doing it, so you will only notice when the fact that never expired turns out to have been wrong about one handler out of four.
Go read your repository's facts. You will either find nothing interesting, which is the good outcome, or you will find the one sentence you are glad you read before an auditor did.
Sources: GitHub changelog, September 25, 2026 · About GitHub Copilot Memory · Managing Copilot Memory as an administrator · Copilot Memory on by default for Pro and Pro+, March 4, 2026
Medium metadata
Title: GitHub Copilot Memory Expires Facts After 28 Days, Unless They Keep Getting Used Subtitle: What the Copilot Memory docs actually promise about retention, scope, and who can read the facts an agent writes about your repository Tags: GitHub Copilot, AI Agents, Agent Memory, Software Security, Developer Tools Canonical: import from fervorai.dev