GitHub Copilot Memory adds repository off switches and CLI controls
GitHub Copilot Memory now has clearer deletion guidance, repository-level controls, and CLI commands, making persistent AI coding context easier to govern.
What changed in GitHub Copilot Memory
GitHub Copilot Memory now adds more administrative and user-facing controls for persistent coding context. GitHub says the public-preview feature has improved deletion guidance, a repository-level off switch, clearer scope prompts, and new /memory commands in Copilot CLI. For teams adopting coding agents, this makes memory less of a hidden behavior and more of a configurable workflow surface.
Key takeaways
- Repository admins can disable Copilot Memory for a repository from existing Copilot feature controls.
- The new CLI commands
/memory on,/memory off, and/memory showlet users control memory behavior across sessions. - GitHub says repository-level facts stop being stored or read after the repository off switch is disabled, but existing facts are not automatically deleted.
- Capture prompts now distinguish user-level preferences from repository-level facts, which reduces ambiguity about who can benefit from or see a memory.
- GitHub Docs describe Copilot Memory as context that can help Copilot cloud agent, Copilot code review, and Copilot CLI work more effectively.
Practical LinkLoot angle
Memory is useful only when teams can inspect, scope, and revoke it. Before enabling persistent memory for coding agents, treat it like a lightweight knowledge base: decide what belongs at user level, what belongs at repository level, and which repositories should not store agent-readable facts at all.
| Memory control | Best use | Limitation | Source |
|---|---|---|---|
| Repository off switch | Disable repository-level memory for sensitive repos | Preexisting facts are not deleted automatically | GitHub Changelog |
/memory CLI commands | Let individual developers inspect and toggle CLI memory status | User choice persists, so onboarding docs should mention it | GitHub Changelog |
| User and repository scopes | Separate personal preferences from shared repository facts | Teams still need review habits for incorrect memories | GitHub Docs |
A practical rollout is to enable memory first on low-risk internal repositories, document approved memory examples, and schedule a monthly review of stored repository facts. If a repository handles secrets, customer data, regulated code, or incident response material, keep memory disabled until your policy explicitly covers it.
What to verify before you act
Check whether your users are on eligible paid Copilot plans and whether your organization or enterprise has enabled Copilot Memory, because GitHub Docs describe different defaults for individual and managed subscriptions. Review existing repository-level facts before disabling memory; the changelog says turning memory off stops future storage and reads but does not delete preexisting facts. Also test the CLI behavior with /memory show in a clean session so your developer documentation reflects what users actually see.
Implementation checklist
- Classify repositories by sensitivity before turning on memory broadly.
- Define examples of acceptable repository-level facts, such as build commands, local setup notes, or test conventions.
- Tell developers which personal preferences are safe to store at user scope.
- Review and delete stale facts after major architecture, framework, or deployment changes.
- Keep a clear escalation path for incorrect or sensitive memories.
If you are designing agent workflows around shared context, pair this with LinkLoot's AI agent tools guide.
It is a public-preview Copilot feature that stores user-level preferences and repository-level facts to help Copilot features work with more context.