Copilot memory reached JetBrains on 11 August: the agent can now retain and recall useful information across chat sessions, so you stop re-explaining your project every morning.
That is a real improvement to a real annoyance. It also quietly changes the failure mode of the whole tool, and that half deserves as much thought as the convenience.
What memory changes about being wrong
A stateless agent that misunderstands your project misunderstands it once, in one conversation, where you can see it happen and correct it.
A stateful agent writes the misunderstanding down. It then applies it consistently, across unrelated tasks, in sessions where nothing looks unusual — and you never witness the moment it was recorded. The behaviour looks like the model getting worse rather than like a stored fact being wrong.
This is not an argument against memory. It is an argument for knowing that "check what it thinks it knows" is now a debugging step, and for being able to inspect and clear that store when the agent starts being confidently wrong in a way that follows you between projects.
Worth remembering
Three categories genuinely pay for themselves, and they share one property: they are stable, and being wrong about them is cheap to spot.
- Conventions — how this codebase names things, structures modules, handles errors. Stable for months, tedious to restate, and obvious when wrong
- Constraints — the framework version you are pinned to, the database you cannot change, the browser you must support. Facts, not judgements
- Preferences about the interaction — that you want the plan before the diff, or tests with every change. These are about you and rarely go stale
Not worth remembering
The other three categories cost more than they save, and two of them are the reason security teams ask about memory at all.
- Anything secret. Credentials, tokens, customer data, internal URLs — a memory store is one more place they live, and GitHub's entry does not say where that store lives or how long it persists
- Anything in motion. The current sprint, the branch you are on, what you were debugging yesterday. Remembered temporary state is worse than no state, because it is confidently out of date
- Judgements about people. "This reviewer is strict", "that team is slow" — an agent repeating this back in six months is a problem with no upside
The unanswered questions
GitHub's announcement says memory can be toggled from the Copilot settings portal. It does not say where memories are stored, how long they persist, or how they are scoped — to a user, a repository, or an organization.
Scope is the one that matters most for a team. Memory scoped to a repository is shared context and mostly a good thing. Memory scoped to a user that travels between repositories is how a fact from one client's codebase turns up while you are working on another's.
Until that is documented, the safe assumption for anyone working across client projects or separated codebases is the cautious one, and the safe practice is not to tell the agent anything you would not want repeated in the wrong room.
Before turning it on for a team
Four questions, none of which need a formal process — but somebody should have answers.
- Can a user see what has been remembered about their work, and delete it?
- What is the scope — does memory cross between repositories, and between clients?
- What happens when someone leaves? Their memories may be more durable than their access
- Who notices if it goes wrong? A stored wrong fact produces slow, diffuse degradation, and nobody is assigned to spot that by default
Keep it pruned
Memory rots in a specific way: the conventions it learned in March describe a codebase that has since been refactored, and it keeps applying them politely and incorrectly.
Make it a habit to review what the agent has retained after any significant architectural change — the migration, the framework upgrade, the module reorganisation. That is exactly when stored conventions become stored fiction.
And if the agent starts being wrong in a way that follows you across unrelated tasks, clear the memory before you blame the model. It is the cheapest test available and it is right often enough to try first.