Copilot Memory: Useful Context Still Needs Evidence

A coding agent can start with a clean conversation and still work in a repository with years of decisions behind it. The interesting question is how much of that context should travel into the next task—and how we know it is still true.

GitHub’s Copilot Memory documentation describes a system that retains repository facts and personal preferences for later work. Its October GitHub Intelligence update connects those memories across several Copilot surfaces. For me, the important design question is not whether an assistant can remember a convention. It is whether a team can examine the evidence behind that convention when the code changes.

Two kinds of memory, two different audiences

A repository fact belongs to a particular repository and can be shared with collaborators. A personal preference describes how an individual likes to work and can follow that person across repositories. Settings, permissions, plan and client support determine whether either kind is created or used; the feature is available on supported paid Copilot plans.

GitHub says repository facts cite code that supports them. When a relevant fact is retrieved, Copilot checks its citations against the current branch. That is a useful feedback loop, but GitHub explicitly describes the check as a model judgment rather than an enforced guarantee. A remembered convention can therefore be missing, stale, misunderstood or simply inapplicable to the current change.

The distinction matters because a style preference and an authorization boundary deserve different treatment. “Explain a patch before applying it” is a preference. “Only this service may issue refunds” is a business and security constraint that must also be enforced by code and verified by tests.

Memory is not a substitute for project instructions

A durable decision should have a reviewable home: architecture documentation, a decision record, a checked-in instruction file, executable tests or a combination of these. Memory can make that material easier for an assistant to find. It should not become the only place a team can discover why an important rule exists.

I would evaluate an agent’s use of memory with three questions:

1. Where did this fact come from? Follow its cited code and check that it actually supports the conclusion.
2. Is it true for this branch and this task? A migration, feature flag or environment can invalidate an otherwise reasonable fact.
3. What enforces it? For consequential behavior, look for tests, access controls or other mechanisms that remain effective even when a model overlooks an instruction.

GitHub documents an automatic voting and expiry mechanism for memories. The default expiry is 90 days; organizations and enterprises can configure repository-fact retention between 7 and 180 days, while user preferences retain the default. Expiry reduces the lifetime of stale context, but it does not prove a retrieved fact is correct today.

Make correction part of the workflow

Memory systems are more useful when the people affected can inspect and correct them. GitHub documents ways to review and delete stored facts and preferences, subject to the relevant permissions and settings. Disabling repository memory stops facts from being created and applied there, but existing facts are not automatically deleted by that switch.

That gives teams a practical review exercise: identify a consequential repository convention, inspect the actual source, and ask whether a new contributor could discover and verify it without relying on an agent’s recollection. If not, improve the repository’s documentation and enforcement first.

In yesterday’s note on code review, I argued that a generated change needs evidence that travels with it. Memory applies the same principle to context before the change: what an agent remembers is useful only when we can tell why it should be trusted.

Sources

• GitHub Docs: About GitHub Copilot Memory.
• GitHub Docs: Managing Copilot Memory.
• GitHub Changelog: GitHub Intelligence.
• Thumbnail includes an excerpt and repository-settings screenshot from GitHub Docs, used under CC BY 4.0; the screenshot is an example of where settings are reached, not an image of a memory itself. GitHub marks are owned by their respective owner; no endorsement is implied.

Sources reviewed on November 5, 2026. Follow jpalanco.com for more notes on AI, engineering and security research.