Copilot Memory is a user policy with repository consequences

GitHub added persistent Copilot memory to its JetBrains plugin on August 11. A developer can now carry useful project details or preferences between agent chat sessions instead of restating them each time. For engineering leaders, the important change is not fewer repeated prompts. It is that retained context has become an administrative decision with effects beyond a single conversation.

GitHub’s broader memory documentation separates what Copilot retains into repository-level facts and user-level preferences. It also says information captured by one Copilot feature can be used by another. Before enabling the feature widely, teams should understand that scope, test how a fact is validated, and decide which instructions must remain explicit and reviewed in the repository.

What did GitHub add to JetBrains?

The August 11 GitHub Changelog says Copilot for JetBrains can now retain and recall useful information across agent chat sessions. Users manage the feature through the Copilot Memory toggle in GitHub’s settings portal.

That release also added Ollama as a bring-your-own-key provider and expanded enterprise controls for plugin availability, MCP server access, permission bypass behavior, and OpenTelemetry. Those are separate changes. Ollama changes model-provider choice; managed settings change client policy; memory changes what context can survive a session. Combining them into one “private AI” conclusion would go beyond GitHub’s claims.

The JetBrains release is the new entry point. GitHub’s Copilot Memory concept documentation describes the larger operating model: repository facts and user preferences may be captured in response to user-initiated Copilot activity, then reused by supported Copilot features.

Which information can cross a session boundary?

Repository-level facts describe a codebase. GitHub’s example is knowledge such as how a repository handles database connections or that settings in two files need to stay synchronized. GitHub says these facts carry citations to supporting code. Before using a relevant fact, Copilot checks those citations against the current branch and uses only validated information.

That is a meaningful control, but it has a precise boundary. Validation shows that the current branch still substantiates the cited fact. It does not prove that the convention is desirable, that every relevant file follows it, or that a remembered inference should replace an approved architecture decision.

User-level preferences describe how a person likes Copilot to work. GitHub says they come from the user’s interactions and are not tied to one repository. That distinction matters because enablement is also per user, not per repository. Once enabled, memory applies wherever that user works with Copilot.

GitHub currently documents Copilot cloud agent, Copilot code review, and Copilot CLI as memory users. It says facts or preferences captured by one feature can be used by another. Code review uses repository facts but not user preferences; CLI uses repository facts and the initiating user’s preferences. The JetBrains changelog establishes cross-session memory in that plugin, but teams should not assume every Copilot surface applies every memory type identically. Check the documented feature boundary as it evolves.

Why does per-user enablement affect repositories?

On individual plans, GitHub says Copilot Memory is on by default. For organization- and enterprise-managed plans, an administrator must first enable the policy, after which individual users can opt out. The switch therefore answers a user-level question: may Copilot learn across this person’s work?

The consequences still reach repositories. Two developers may approach the same codebase with different user preferences. A repository fact learned during one feature’s work may later inform another feature. Meanwhile, a teammate who opted out may rely only on the current prompt and explicit repository instructions.

This does not make memory inherently unsafe. It means memory is not a substitute for versioned instructions. A convention that must apply to every change—an authorization rule, generated-file policy, release command, or required test—still belongs in reviewed repository documentation and executable checks. Memory can reduce repetition around useful context; it should not become the only place a mandatory rule exists.

How does retention reduce, but not remove, stale context?

GitHub says an unused fact or preference is automatically deleted after 28 days. The timer may reset when Copilot successfully validates and uses the entry. Repository facts from pull requests that closed without merging can also be captured, but GitHub says current-branch validation prevents them from affecting behavior unless the codebase still supports them.

The 28-day rule is expiry based on use, not a guarantee that every retained item becomes incorrect on day 29 or remains correct through day 28. Reuse may extend retention. Current-code validation can protect a repository fact whose citation changed, but user preferences are not tied to repository citations in the same way.

Treat retention as one lifecycle mechanism rather than the whole control. A team still needs to know how users inspect and remove retained information, what happens when a convention changes, and whether a durable rule should be moved out of memory and into source-controlled instructions.

What should a bounded rollout test?

Start with one representative repository and a small group of developers who use JetBrains plus at least one other documented Copilot surface. Do not change model provider, MCP policy, permission bypass, and memory policy in the same test. Holding those variables steady makes memory behavior easier to observe.

Use two deliberately harmless items:

1. A repository fact supported by specific code, such as the location of a test fixture or the required pairing of two configuration files.
2. A user preference that affects presentation rather than correctness, such as a preferred explanation style.

Then test each item through creation, a new chat session, a second supported Copilot feature, a branch where the cited code changes, and manual deletion. Record whether the item appears, whether its citation is still valid, which feature used it, and whether the developer could inspect and remove it. Do not seed secrets, customer data, or access credentials merely to see whether memory can recall them.

A passing trial should show more than successful recall. The repository fact should stop influencing work when current code no longer substantiates it. The user preference should not be mistaken for a repository requirement. Mandatory engineering rules should continue to work for a developer who has memory disabled.

Where should the durable rule live?

Use Copilot Memory for context that benefits from continuity but can tolerate the documented lifecycle and feature boundaries. Keep binding team instructions in the repository, where they can be reviewed, changed, and tested with the code. Put security and quality invariants into executable controls whenever possible.

That division keeps the convenience without making invisible retained context the source of truth. Memory can remind Copilot how a codebase usually works. The repository and its checks should still decide how a change is allowed to work now.

GitHub’s JetBrains release makes that decision timely for teams already using Copilot across IDE, CLI, review, and cloud-agent work. Enable memory as a bounded user policy, verify its repository consequences, and expand only when developers can explain what was retained, where it can reappear, and how it stops applying.

BaristaLabs helps engineering teams evaluate AI development features against policy, evidence, and operating ownership. Explore AI consulting and strategy, or bring one representative repository to a focused memory-boundary review.