GitHub Copilot Memory Gets Controls: AI Memory Now Needs Governance

Memory seems like an obvious advantage for a programming assistant. If AI remembers project patterns, team preferences, and previous decisions, it wastes less time asking the basics. But the same memory that saves minutes can also store wrong, outdated or sensitive context. Therefore, the news about GitHub Copilot Memory is not just about productivity. It's about control.

On May 26, 2026, GitHub announced new features for Copilot Memory, still in public preview for paid plans. The update includes better guidance for memory deletion, per-repository shutdown, and /memory command in the Copilot CLI. The change seems small, but it touches on the heart of the next phase of code assistants: how to continue without turning context into permanent risk.

What happened

Copilot Memory allows the assistant to store user preferences and repository facts. With the update, when someone asks to forget information, Copilot now indicates the correct place to delete that data. Administrators can also disable memory in a specific repository, preventing reading and writing of facts in that scope.

In the CLI, the /memory command helps to query status and control the resource. GitHub also explained better whether information will be saved as a personal preference or as a repository fact. This distinction is important: "I prefer testing with Vitest" does not have the same weight as "this service authenticates users through an internal flow".

The technique behind

Code helpers are context dependent. Without it, they generate generic responses. With too much context, they can mix up projects, repeat old decisions or expose undue information. Memory attempts to resolve this balance by creating a persistent layer between sessions. The challenge is that persistence changes the nature of the tool: it stops being just a temporary answer and becomes part of the team's knowledge infrastructure.

Therefore, scope is as important as capacity. A personal memory must follow the user. A repository memory must be locked into the project. Sensitive information may never be remembered. The real progress is in making these borders visible and manageable.

Why this matters

Engineering teams already live surrounded by context: issues, PRs, ADRs, READMEs, wikis, logs and conversations. AI promises to sew all of this together, but the seam needs to be auditable. If an assistant suggests code based on an incorrect memory, who notices? If he maintains a rule that is no longer valid, how does the team correct it? If he learned something from a private repository, where does that data reappear?

The new controls don't solve all of these problems, but they point in a healthy direction. AI memory must have an off button, review track and clear boundaries. Without this, agentic assistants can speed up errors as efficiently as they speed up tasks.

The future it anticipates

The next step for devtools won't just be completing better code. It will be maintaining an ongoing relationship with the project. The AI ​​will remember patterns, review changes, open PRs, run tests and suggest architecture. In this world, forgetting also becomes a security function.

The question for teams is an uncomfortable one: if AI starts to remember how your system works, who within the organization will be responsible for reviewing what it believes it knows?

What to watch out for

The feature is still in preview, so the most important point will be to observe how real teams organize usage policies. A small team may accept memory bound by default. A larger company may need to separate critical repositories, experimental projects, and sensitive data environments. The right configuration will not be universal.

It will also be important to keep track of how conflicting memories will be handled. Projects change framework, convention and architecture. If the Copilot keeps an old preference, he may suggest decisions that seem coherent, but no longer make sense. Resource quality will depend on editing, expiration, and review, not just collection.

There is a cultural shift embedded here. Developers are used to reviewing code, but not necessarily reviewing tool memory. In the near future, keeping the AI ​​context clean could become part of engineering hygiene, as well as updating documentation, removing old feature flags and archiving decisions that have expired.

Sources

1. https://github.blog/changelog/2026-05-26-copilot-memory-has-more-controls-for-deletion-scope-and-the-copilot-cli