GitHub Copilot can now carry repository facts across JetBrains sessions and connect to Ollama models. The convenient part is remembering. The important part is knowing whose memory it is, where it appears, and when it disappears.
GitHub Copilot Memory has arrived in the JetBrains plugin’s 1.15 release, alongside Ollama bring-your-own-key support and new enterprise controls. Copilot can retain repository facts between sessions instead of rediscovering the same conventions every time.
That can remove repetitive setup. It can also preserve a wrong assumption long enough to look like project truth. GitHub’s inspection, deletion, and expiration controls should be part of the rollout, not a cleanup exercise later.
Repository facts and user preferences travel differently
| Memory type | Scope | Where it can appear | Who can manage it |
|---|---|---|---|
| Repository fact | One repository | Coding agent, code review, and Copilot CLI | User and repository owners |
| User preference | Same user across repositories | Supported Copilot experiences, but not code review | User; managed-plan admins can export or delete |
A repository fact might record the test command, architecture rule, or directory convention. A user preference might remember how one developer wants explanations or code organized. GitHub says user preferences do not flow into code review, which avoids injecting one reviewer’s personal style into shared review output.
The 28-day rule is an inactivity timer
GitHub automatically deletes a memory after 28 days without use. Validation or use resets the timer. A frequently reused memory can therefore live much longer than 28 days.
That design favors useful context, but it can also keep stale guidance alive. Imagine a remembered deployment command that still works after the team changes its release policy. Each successful reuse extends the memory even though the instruction is no longer desirable.
Expiration removes forgotten memory. It does not prove that active memory is correct.
Managed organizations must opt in first
GitHub says Copilot Memory is on by default for individual users. Business and Enterprise organizations must enable it before members can use it, and users can still opt out. Administrators can export or delete user preferences and receive audit events for certain memory operations.
The sensible policy is to enable memory repository by repository. Start with projects that already have clear instructions and owners. A messy repository will teach the system a messy working model.
Ollama support does not make the entire workflow local
The same JetBrains release adds Ollama as a model provider. That gives developers a route to models running through their Ollama setup. It does not, by itself, prove that every Copilot feature, memory operation, telemetry event, tool call, or agent service stays on the machine.
Before describing the setup as private or offline, capture traffic during the exact workflow and check GitHub’s product documentation. “The model endpoint is local” is a narrower claim than “the coding assistant is local.”
A five-step memory rollout
- Inventory existing instructions. Fix README, agent, and repository guidance before memory learns around contradictions.
- Name an owner. Someone must review stored facts after architecture and workflow changes.
- Inspect before trusting. Ask developers to read the memory list and delete facts they cannot verify.
- Test stale context. Change a command or convention and measure how quickly the old memory stops affecting output.
- Log the provider path. For Ollama, verify which steps are local and which still contact GitHub services.
Our agent-memory evaluation guide treats a fresh session as the baseline, which is the right test here. The Claude Code cross-session messaging checklist also shows why persistent state needs permissions and cleanup rules.
My verdict: memory earns its place one fact at a time
Copilot Memory can make a long-running repository feel less like a cold start. I would enable it where the team can inspect the stored facts, compare results with memory off, and remove bad context quickly.
The feature should not become an invisible second documentation system. If a memory matters enough to guide production code, it probably belongs in version-controlled instructions too.
Read the primary sources
- Read GitHub’s JetBrains 1.15 release note.
- Review the Copilot Memory concept documentation and administrator controls.
Checked August 12, 2026. Memory scope, expiration, availability, and controls are reported by GitHub. Ollama’s end-to-end data path should be verified against the specific deployment.
