Copilot Memory now has an off switch, and agent memory becomes a permissions problem

AI 요약

• What happened: GitHub added deletion guidance and a repository-level off switch to Copilot Memory on May 26, 2026.
  • Copilot CLI now supports /memory on, /memory off, and /memory show, with the choice persisting across sessions.
• Scope: The store_memory permission prompt now distinguishes user-level preferences from repository-level facts.
• Watch: Turning Memory off for a repository stops future repository facts from being read or written, but it does not automatically delete existing facts or personal preferences.

GitHub published a Copilot Memory controls update in the Changelog on May 26, 2026. The announcement is short: better deletion guidance, a repository-level off switch, and new /memory commands in Copilot CLI. For developers, the useful signal is not the feature name. It is the boundary. Once a coding agent can remember repository conventions and personal preferences across sessions, the controls for who can see, disable, delete, and re-inject that memory become part of the product itself.

This is not a model launch or a benchmark result. It is an operating-surface update for Copilot Memory, which GitHub already runs as a public preview. GitHub says Copilot Memory is available on all paid Copilot plans. GitHub Docs describes the feature as a way to store repository-level facts and user-level preferences so Copilot cloud agent, Copilot code review, and Copilot CLI can work more effectively. The design mirrors how a human developer adapts to a codebase: read the README, learn conventions, notice cross-file dependencies, and carry that knowledge into the next task.

GitHub's memory experiment began with the January 15, 2026 public preview. At that point, GitHub said Copilot coding agent, Copilot CLI, and Copilot code review could share repository-specific memory. A convention learned in one Copilot surface could influence another surface's review or CLI session. On March 4, GitHub turned Memory on by default for Copilot Pro and Pro+ users in public preview. On May 15, GitHub added early access to user-level preferences for Pro and Pro+ users. The May 26 update is the control layer that follows those rollout steps.

The first new control is deletion guidance. When a user asks Copilot to forget something, GitHub says Copilot now points the user to the correct place to remove that memory and down-votes the memory on surfaces where voting is available. That wording matters. It does not promise that a natural-language "forget this" command automatically deletes every stored record. It connects the user's request to the product location where deletion should happen. For teams, that difference matters when an agent has stored a sensitive convention, an internal path, a customer name, or a temporary migration rule.

The second control is a repository-level off switch. Repository admins can disable Copilot Memory from the existing Copilot feature controls in repository settings. GitHub says repository-level facts are no longer read or written when that switch is off. But the same announcement states that preexisting facts are not deleted, and user-level preferences are not affected. "Turned off for this repository" therefore means future repository fact read and write operations stop. It does not mean every previously stored memory and every developer's personal preference disappears in one action.

The third control is Copilot CLI support. GitHub lists /memory on, /memory off, and /memory show. A user can enable, disable, or inspect Memory from the terminal, and the choice persists beyond the current session. That is more consequential than it first sounds. Terminal-based coding agents often run close to sensitive work: security patches, customer-specific branches, licensing reviews, migrations, and production scripts. A CLI-level command gives the developer a quick way to check whether the current agent session is using long-lived repository knowledge before continuing.

The fourth change is scope labeling at save time. The store_memory permission prompt now states whether an item is a user-level preference or a repository-level fact. A user-level preference belongs to one person and can apply across repository sessions. A repository-level fact is visible to repository contributors who have access to Memory. As a UI tweak, that may look small. As an agent-memory mechanism, it is the permission model. "I prefer to review tests first" and "this repository keeps billing code under packages/billing" should not have the same storage scope or audience.

The retention rule in GitHub Docs is part of the same governance story. GitHub says stored facts or preferences are automatically deleted after 28 days if they are not used. That number makes Memory look less like a permanent knowledge base and more like working context with an expiration rule. It does not close every governance question. A wrong memory can affect the next pull request review or CLI task immediately, and a used memory still needs stale-context checks. GitHub says repository facts are validated against the current codebase, but teams should test how validation failures appear in the specific surfaces they use.

The practical value of this update is not "Copilot can remember." It is "the memory's scope is now more visible." If a coding agent ends after one session, reviewers can inspect the prompt, the diff, the logs, and the commands it ran. Once an agent reuses state across sessions, the review surface expands. Teams have to care about where a fact came from, who had permission to create it, who can read it, how it expires, how it is deleted, and what happens when a personal preference conflicts with team convention. GitHub's distinction between user preferences and repository facts maps directly to that checklist.

For enterprise teams, the repository off switch should become a procurement and rollout question. Security reviewers should not stop at "can Memory be disabled?" The more precise question is "what remains after we disable it?" GitHub's Changelog explicitly says existing facts are not deleted by the repository-level off switch. A safe process for sensitive repositories therefore has two steps: disable future repository fact read/write behavior, then inspect or delete already stored facts in the Copilot Memory area of repository settings. Account-management docs should also state that user-level preferences live in a separate scope.

For individual developers, /memory show is a small but useful guardrail. If a terminal agent suddenly knows a repository convention too well, it is worth checking whether that knowledge came from the current file search or from stored Memory. /memory off can be useful during security patches, customer-specific work, license reviews, incident follow-ups, or any session where the team does not want new repository facts to be learned. The CLI toggle should not be confused with organization policy, though. GitHub presents CLI controls and repository settings as separate management surfaces.

Community discussion around Copilot Memory has focused less on the convenience of remembering and more on storage location and correction. In GitHub Copilot threads, developers have asked where memory is stored, how to fix incorrectly inferred repository knowledge, and how product memory should relate to explicit files such as AGENTS.md or .github/copilot-instructions.md. The positive case is clear: repeated explanations shrink, and code review and CLI sessions can share repository context. The concern is also clear: portability, auditability, hidden-prompt confusion, and support outside the expected GitHub repository environment.

GitHub's approach is different from file-based memory. AGENTS.md, README files, docs, and .github/copilot-instructions.md live in the repository and can be reviewed in Git. Copilot Memory is dynamic product state created through settings and permission prompts. Files are explicit and portable, but they can become stale. Product memory can reuse facts discovered during work, but responsibility moves into account permissions, repository settings, and product UI. The May 26 update does not replace one model with the other. It adds missing controls to the dynamic-memory side.

A lightweight adoption checklist starts with four items. First, repository owners should verify where current facts are visible and who can delete them. Second, teams should decide whether sensitive repositories use Memory by default or require explicit opt-in. Third, engineering leads should document what wins when a personal preference conflicts with a repository convention. Fourth, developers working on sensitive branches should run /memory show before letting a terminal agent continue. None of these steps measure model quality. They manage the state that an agent may carry into the next task.

The competitive axis is also moving away from model names alone. Copilot, Codex, Claude Code, Cursor, Gemini, and other coding-agent tools all need an answer for project memory. Some tools read instruction files. Some store session history. Some maintain repository facts as product state. Teams comparing tools should ask whether memory is scoped to a user or repository, whether citations or provenance are available, whether admins can disable it, whether users can inspect it from the CLI, and whether retention is documented. Those questions affect trust as much as code-generation quality does.

Copilot Memory is still in public preview, and GitHub Docs say preview features can change. User-level preferences are described for Copilot Pro and Pro+ users in early access. Enterprise and organization rollouts mix paid plans, repository settings, feature availability, and policy controls. Before a team treats Memory as a standard development surface, it should verify three behaviors with real accounts: whether Memory is enabled across the organization, whether repository owners can inspect facts, and exactly which surfaces are affected when an individual developer runs /memory off.

Read narrowly, the May 26 Changelog adds a few settings and commands. For teams using coding agents as long-running collaborators, it asks a more direct question. If an agent carries repository knowledge into next month's reviews and CLI sessions, memory is both a productivity feature and a governance feature. GitHub bundled deletion guidance, a repository off switch, CLI commands, and scope prompts in the same update because those controls belong together. In the agent-memory era, the baseline UI is not only "the assistant got smarter." It is "what did it remember, where is it stored, and who can remove it?"