GitHub Copilot Memory Controls: How to Manage, Delete, and Disable (May 2026)

If your team uses Copilot Business or Enterprise and you want a clean answer before the June 1 billing shift, here it is. As of May 26, 2026, repository admins can flip Copilot Memory off at the repo level under Repository Settings > Copilot > Memory. Existing facts stay in storage but stop being read. Individual developers get three new CLI commands (/memory on, /memory off, /memory show) for per-session control. Deletion routing improved. Capture-time prompts now label each entry as a user-level preference or a repository-level fact so contributors know what they are agreeing to store. Keep Memory on if you want Copilot to learn your codebase patterns over time. Turn it off at the repo level if your codebase carries IP you do not want indexed, if you have compliance requirements, or if you want deterministic behavior during the billing audit window.

GitHub published the changelog on May 26, 2026 (see the official changelog entry). Four controls shipped at once. We walk through each one below, in the order admins are most likely to need them.

What Copilot Memory stores and who can see it

Copilot Memory is a persistent context layer. Instead of starting every chat or completion request from zero, Copilot keeps short structured notes about you, your codebase, or both. The point is to skip the warm-up. You say "use our internal logging helper" once, and Copilot remembers next session.

There are two kinds of stored memory. The distinction matters more than anything else in this article.

User-level preferences. These are tied to your GitHub account. They follow you across repositories. Example: "I prefer pnpm over npm." Only you see your own user-level preferences. Per the GitHub Copilot Memory docs, user-level preferences are available on Pro and Pro+ plans.

Repository-level facts. These are stored against a specific repo. They are visible to every contributor on that repo. Example: a contributor asks Copilot to remember "this project uses Postgres 16 with the pgvector extension." That fact is now part of repo context for everyone else who uses Copilot against the same codebase.

That second point is the one most teams miss. A repository-level fact is not a private note. It is a shared resource for the repository's contributor list. If a contributor's chat captures a fact about your auth flow, your data model, or your deployment topology, every other contributor with Copilot access on the repo sees it surfaced when Copilot deems it relevant.

GitHub's docs also confirm a 28-day automatic cleanup rule. Memory entries that are not reinforced or referenced are aged out automatically after 28 days. That bounds how long any single stored fact persists by default, which is useful context for compliance reviews.

The new repository-level off switch (May 26, 2026)

This is the headline change. Before May 26, a repo admin had no per-repository way to stop Copilot from capturing facts about a codebase. The only options were org-wide policy or accept it. Now there is a toggle.

Where to find it. Repository Settings > Copilot > Memory. The toggle is at the top of the Memory section. Admin role required. Below the toggle, GitHub surfaces the existing repository-level facts so you can see what is currently stored before you change state.

What turns off when you flip the switch. Two things stop. New facts are no longer captured against the repository. Stored facts are no longer read into Copilot's context when contributors interact with the repo. That second part is the one teams care about for compliance: the off switch is a read-and-write block, not just a write block.

What does NOT change automatically. Existing repository-level facts remain in storage. They are not deleted by toggling the switch off. If you want them gone, use the deletion flow described below. The reasoning here is reasonable. An admin might toggle off temporarily during an audit, then toggle back on. Auto-deleting on toggle would destroy team context that took weeks to build up.

Who needs this control today. Three groups. Compliance-bound teams (finance, healthcare, defense subcontractors) where shared context across contributors triggers data-handling review. Teams with sensitive IP in the codebase where any new indexing surface is opted into deliberately. Any team running a Copilot audit ahead of the June 1 shift to usage-based billing for Business and Enterprise plans, where reducing surface area before metering goes live is a reasonable precaution.

If you administer a Copilot Business or Enterprise org, the toggle is the most concrete admin lever the platform has shipped in months. Worth using or not using on purpose, rather than by default.

The /memory CLI commands

The Copilot CLI got three new sub-commands. These are session-level controls for developers, not admin controls. Per the GitHub changelog, state persists across CLI sessions, which means you set it once and it stays set.

# Check current memory state in the Copilot CLI
/memory show

# Disable memory for this and future sessions
/memory off

# Re-enable memory
/memory on

A typical workflow looks like this. You open the Copilot CLI. You run /memory show to confirm current state. If you are working on a sensitive task and want Copilot to behave deterministically without pulling stored context, you run /memory off. The setting persists. When you are done and want adaptive behavior back, run /memory on.

Why this matters even if your repo admin has not flipped the repo-level switch. The CLI command is the developer-side opt-out. Repo-level off is the admin saying "no team memory here." CLI off is the individual developer saying "no memory in my CLI session right now." The two controls compose. A developer can have /memory off set in their CLI while the repo has memory on for other contributors using the IDE plugin.

The persistence behavior is worth flagging. Other CLI commands reset per session. /memory does not. If a developer flips it off six months ago and forgets, every CLI session since has run without memory, which can be surprising during debugging. Run /memory show first if Copilot is acting differently than a colleague's setup.

How to delete specific memories

Before May 26, asking Copilot to "forget that" inside a chat was a coin flip. Sometimes it acted on the request, sometimes it just acknowledged the request without doing anything. The May 26 update routes deletion requests to the correct removal path and down-votes the entry where voting is available. The chat now treats forget-style requests as actions, not as conversation.

For explicit deletion you have two paths.

Deleting user-level preferences. Go to your personal Copilot settings. The Memory page lists every user-level preference Copilot has stored about you. Check the boxes for entries you want removed and confirm. Bulk delete is supported. These are your preferences, so no other contributor or admin can delete them for you, and you cannot delete another developer's user-level entries from your account.

Deleting repository-level facts. Repository Settings > Copilot > Memory. Same panel that has the off switch. Below the toggle, the panel lists repository-level facts. Admin role required to delete. Bulk delete is supported here too. This is the place to wipe specific facts you do not want shared while keeping memory on for everything else.

Down-voting via chat. The May 26 deletion guidance change means that if a contributor tells Copilot in chat to forget a specific repository-level fact, Copilot now routes them to the deletion page AND records a down-vote on the entry where voting is available. Down-votes do not delete the entry on their own. They signal low value, which factors into Copilot's relevance scoring. For a hard delete, the settings panel is still the source of truth.

What about org-wide. Enterprise admins can disable Copilot Memory at the org level under the Copilot policy controls. That is the nuclear option. It overrides repository-level toggles for every repo in the org. Useful if your security review concludes memory is out of scope for the company entirely. The per-repo toggle exists precisely so that org-wide disable is not the only choice.

Should your team keep Copilot Memory on?

Decision-stage section. Here is the framework.

Keep Memory on if your team works on the same codebase week after week and benefits from Copilot picking up your conventions over time. A team with a stable repo and an internal style guide gets a real productivity win from memory accumulating "we use this logging pattern" or "imports go in this order." If you already pay for GitHub Copilot Business or Enterprise specifically for the team-context features, leaving memory on is the answer most weeks.

Turn Memory off at the repo level if any of the following describe your situation:

1. The repo holds proprietary IP or customer data shapes you would rather not have indexed beyond the git contents themselves.
2. Your compliance regime (SOC 2 Type II, HIPAA, certain financial services controls) treats shared cross-contributor context as in-scope for review, and you have not yet completed that review for Copilot Memory specifically.
3. You are mid-audit on Copilot usage and want a deterministic baseline before billing changes on June 1. Toggling memory off during the audit window means the team's usage numbers reflect the metered behavior, not memory-amplified context retrieval.
4. Your team prefers predictable, non-adaptive Copilot behavior. Some senior engineers find that memory-backed suggestions drift from documented patterns over time. Off gives you the stable baseline.

Use the CLI controls if the answer is per-developer rather than per-repo. A lone contributor working on a sensitive change inside an otherwise memory-on repo runs /memory off in their CLI session and gets the deterministic behavior without forcing a team-wide change.

The June 1 billing context is the timely piece. GitHub shifts Copilot Business and Enterprise to usage-based billing on June 1, 2026 (see our Copilot usage-based billing guide for what counts as metered usage). Many teams are running a one-week audit pre-metering. Toggling memory off for the audit window is a defensible call. Doing nothing is also a choice, just make it on purpose.

If you run the GitHub Copilot App preview for parallel agent sessions, the repo-level off switch covers those agents too.

FAQ

Does disabling repo memory affect user-level preferences? No. The repo-level off switch only blocks repository-level facts from being stored and read for that repository. Your personal Copilot preferences continue to follow you across other repos where memory is on.

Which Copilot plans support Memory? Per GitHub's docs, user-level preferences require Pro or Pro+. Repository-level memory ships on the paid Business and Enterprise tiers. The free plan does not include Memory. If you are evaluating which tier fits your team, the GitHub Copilot plans page is the current reference.

How do I know which entries are user-level vs repository-level? The May 26 update added explicit scope labels to the capture-time store_memory permission prompt. When Copilot asks to store a new memory, the prompt now labels the entry as either a user-level preference (visible only to you) or a repository-level fact (visible to all contributors on that repo). You see the label before you accept. Existing entries are also labeled in the Memory settings panels for retrospective review.

Can a repo admin delete individual developer memory entries? Repo admins can delete repository-level facts for the repos they administer. They cannot delete a developer's user-level preferences. Those are personal to the account. Org owners on Enterprise plans can disable Memory entirely for the org via policy, which is broader than per-user deletion but does not target specific entries.

What happens to existing memories when I use the off switch? They stay in storage. The toggle stops new captures and stops existing facts from being read into Copilot context. To remove the existing facts, use the bulk-delete flow in the same Memory settings panel. The 28-day cleanup rule from GitHub's docs also still applies, so unreferenced facts age out automatically over time even if you forget to clean up manually.

Does Copilot Memory affect what counts toward usage-based billing on June 1? GitHub has not published a final mapping of memory operations to billed events. Memory-amplified context retrieval may increase request size, which feeds into the per-request cost basis. Teams running a baseline-usage audit may want to flip memory off during the audit window for a clean read on metered usage.

What about Copilot agents? Agents read from Memory when it is enabled. The repo-level off switch covers them. Persistent context is what lets an agent pick up a multi-step task across sessions, so disabling memory makes agent behavior more stateless and predictable.