Copilot Memory: the CLI controls
Published 2026-05-27 by Owner
GitHub Copilot’s Memory feature got CLI controls in the changelog dated May 26. Three slash commands and a clarified permission prompt change how you read and audit what Copilot has stored about your work. This guide walks the four pieces.
Turn memory on and off per session
The CLI now accepts /memory on, /memory off, and /memory show. Per the GitHub blog, the settings persist across sessions:
/memory on
/memory off/memory off does not delete stored memories; it stops Copilot from reading or writing memory for the duration of the setting. Re-enable with /memory on.
Inspect what’s stored
Before assuming you know what is in your memory, list it:
/memory showThe output shows the entries Copilot has accumulated. If you have been using Copilot for several weeks before this release shipped, the list may contain entries you do not remember approving — the permission prompt before May 26 did not distinguish the user-level vs repository-level scope that the new prompt makes explicit, so audit the list before assuming the entries reflect your intent.
Read the scope at capture time
The most consequential of the changes is to the store_memory permission prompt itself. Per the GitHub blog: “The store_memory permission prompt now explicitly states whether the entry will be a user-level preference or a repository-level fact.”
The difference matters. A user-level preference travels with your account across every repository you touch — “this user prefers two-space indentation” follows you. A repository-level fact stays scoped to the repo you are in — “this repo’s deploy script lives at bin/deploy.sh” is correct only here. Before the May 26 change, those two went through the same prompt, and you could store one thinking it was the other.
When the prompt fires, read the scope line carefully and approve only if the scope matches the actual nature of the entry. A coding convention is user-level. A deploy command path is repository-level. Mis-scoping a repository-level fact as a user-level preference is the failure mode the new prompt is trying to prevent.
Ask Copilot to forget
When you want a memory removed, the response now points to the right place to delete it. Per the GitHub blog: “When you ask Copilot to forget something, it now points you to the right place to remove the memory and down-votes the memory where voting is available.”
The down-vote step matters: it does more than delete the single entry. Down-voting flags the pattern so Copilot is less likely to re-derive the same memory in a similar future situation. If you find yourself asking Copilot to forget the same thing twice, the down-vote is the lever to push.
What this guide does not cover
Two pieces deserve mention but are out of scope here. First, per-repository admin off-switches for org-managed repositories: the GitHub blog does not document the admin UI path in detail and inventing one risks shipping a wrong instruction. Consult your repository’s Copilot settings page directly for the toggle. Second, enterprise-level memory governance: the targeted model rules ship in the same May 26 changelog window but are a separate feature with their own configuration; the relevant news article is Copilot adds per-organization targeted model rules.
A short audit checklist
Once a week is enough — more often if you work across many repositories:
/memory showFor each entry whose scope does not match your intent, ask Copilot to forget it and confirm the down-vote. The list should reflect the convention you would have approved if the new scope-at-capture prompt had been in place from day one.
The argument for why the per-tier governance matters is in the org chart picks your model; the model-rules news article is Copilot adds per-organization targeted model rules; the related audit pattern for surfaces beyond memory is auditing MCP config for leaked secrets.
