💬 Feedback wanted: Copilot Memory now on by default for Pro and Pro+ users in public preview

[ebndev]

We’ve officially enabled Copilot Memory by default for all GitHub Copilot Pro and Copilot Pro+ users.

Previously available as an opt-in public preview, Copilot Memory now automatically builds and retains a persistent, repository-level understanding of your codebase — so you spend less time re-explaining context and more time shipping code.

⭐ This discussion is your space to try it, push it, and tell us what’s working (and what’s not).
We’re especially interested in how memory behaves in real repositories and real workflows.

---

🧠 What is Copilot Memory?

Copilot Memory allows Copilot agents to discover and store useful facts about a repository — such as coding conventions, architectural patterns, and important cross-file dependencies — and reuse that knowledge in future interactions.

A few important characteristics:

• Repository-scoped – Memories are limited to a single repository.
• Validated in real time – Stored knowledge is checked against the current codebase before being applied, so stale or inaccurate context isn’t used.
• Auto-expiring – Memories automatically expire after 28 days to keep things fresh.
• Cross-agent by design – Knowledge discovered by one agent can immediately benefit another.

Once enabled, Copilot Memory works across:

• Copilot coding agent – Applies repository-specific context when implementing tasks and opening pull requests.
• Copilot code review – Uses learned patterns to provide more accurate, targeted review feedback.
• Copilot CLI – Brings repository awareness directly into your terminal workflow.

Because memories are shared across agents, something learned during code review can improve coding suggestions — and vice versa.

---

🔄 What’s changed?

Copilot Memory is now on by default for individual users on Copilot Pro and Copilot Pro+ plans.

No action is required to start benefiting from it.

If you prefer to opt out, you can disable Copilot Memory anytime in your personal Copilot settings under:

Features → Copilot Memory

Enterprise and organization admins continue to have full control over memory availability for their members through Copilot policies.

---

🔍 Where we’d love your feedback

We’re curious how memory shows up (or doesn’t) in your everyday work. For example:

• Did Copilot correctly learn and reuse a convention in your repo?
• Did it fail to remember something you expected it to?
• Did memory ever surface something outdated or incorrect?
• Did cross-agent behavior (e.g., coding agent → code review) actually save you time?
• Did it improve across repeated interactions?

If you’ve tried memory on a real pull request or task, we’d love to hear about it.

---

⚙️ Managing memories

Repository owners can review and delete stored memories at any time under:

Repository Settings → Copilot → Memory

For more details:

• About agentic memory for GitHub Copilot
• Enabling and curating Copilot Memory

---

📣 How you can help

Please comment below with:

• Which agent you used (coding agent, code review, CLI)
• The type of repository or workflow
• What Copilot remembered that was helpful
• What it missed or got wrong
• Anything that surprised you (good or bad)
• Suggestions for what Copilot should remember next

Screenshots, prompts, or concrete examples are especially helpful.

---

🙏 Thank you

Cross-agent memory is a foundational step toward Copilot feeling less like a stateless tool and more like a teammate that actually learns your codebase over time.

Now that it’s enabled by default, your feedback matters even more. It directly shapes how memory evolves as we expand it to more agents and workflows.

We’re excited to hear how it behaves in the wild — and what you want it to learn next.

[beingminimal]

@ebndev This is really a great feature and congratulations on this achievement.

Can you please answer below questions to get some clarity and make this feature more useful?

1. Can we give few files into memory like PRD of repo or vision of repo or anything?
2. Copilot memory will also work with copilot sdk? if yes then how?
3. How we can use this to plan new issues for repo based on memory and current state of code and issues in repo? is there any way through which we can solve this?

[patniko]

Hi @beingminimal -

1. In the future we will move in that direction, but right now it is focused mostly on shared optimizations/learnings. Would be great to use it to drive down need for instruction files, but there is some debate around what should be in a repo since it is helpful to humans vs. what should be in something that is designed mostly for agents.
2. Not currently in the SDK, but we are looking at that right now. Our SDK should be close to the CLI capabilities, but some design goals are different.
3. Curious to know more about what you are looking for on this one. What workflow do you imagine?

Thanks for the questions!

[PureWeen]

I realize this is probably the opposite of why the memory feature exists :-) but it'd be neat if memories good be mined for improvements to Custom Agents/Skills/Instructions/Repository knowledge. It could even be used as a way to find inconsistencies against instructions. A memory could tag that it's out of sync with how instructions dictate knowledge.

Proposal: Provide a path for validated memories to graduate to permanent instruction files.

The Ask

1. Surface memories for review - Let teams see what Memory has learned
2. Graduate to instructions - Convert high-confidence memories into permanent instruction files (.github/copilot-instructions.md, path-specific .instructions.md)
3. Validate instructions against learnings - Flag when agents learn something that contradicts or extends existing instructions

Why Graduation Matters

The 28-day expiration works for evolving patterns. But some learnings should become permanent:

• Memory learns "always check both ISafeAreaView and ISafeAreaView2" repeatedly → should be an instruction
• Memory learns "Platform layer can't reference Controls layer types" → should be in ARCHITECTURE.md
• Memory keeps re-learning the same thing → signal that it's not documented

Without graduation, valuable learnings expire. With graduation, the repository accumulates knowledge permanently.

Why This Matters for Adoption

Instructions are powerful but underutilized. Teams don't iterate on them because:

• No visibility into what agents are learning
• No signal showing "this should be documented"
• Instructions feel like one-time setup, not a living system

Memory → Instructions graduation changes this:

Memory learns X → X persists/repeats → "X should be an instruction"
    ↓
Team reviews → Adds to instructions → Future agents succeed immediately

Every interaction becomes a feedback loop that improves repository context.

The Workflow We Want

Developer: "What has Memory learned that should become instructions?"

Copilot: "These patterns keep appearing:
  1. [repeated] SafeAreaView has v1 and v2 interfaces - always check both
  2. [repeated] Platform layer can't reference Controls layer types
  3. [recent] Specific pattern for this area - may not be general yet
  
  → Recommend adding #1 and #2 to handlers.instructions.md"

Or at the end of any session:

Developer: "Based on what you learned, how could we improve our instructions?"

Copilot: "I discovered that X isn't documented but I needed it. 
         Suggest adding to copilot-instructions.md."

The Gap

What Exists	What's Missing
Copilot Memory (28-day, auto-generated)	Visibility into what Memory has learned
Instruction files (permanent, manual)	Memory → instruction suggestions
Memories auto-expire	Graduation path for validated learnings

Minimal Version

Surface what Memory has learned and suggest which learnings should become instructions. We'll handle the actual file updates ourselves.

References

• Agentic memory public preview (Jan 2026)
• Copilot Memory docs

Related issues:

• CLI #667 - Persistent memory across sessions
• CLI #377 - Memory visibility and /memory command
• Community #162797 - Persistent memory for preferences

Our request extends Memory with: visibility, graduation path to instructions, feedback loop for instruction improvement.

[filip-be]

Hi @ebndev!

I love the memory feature, I believe this can greatly improve agentic behavior!

What worked well

Copilot Coding Agent was unable to restore packages from private feeds.
We have configured some secrets on copilot environment and was able to instruct the agent to use that when restoring packages.

Following sessions use that pattern consistently which proves the memory works well in such case!

What doesn't work well

Most of the time we cannot see memories in repository settings 😢

I was able to see them yesterday:

But today they are not available anymore:

Context

We are using GitHub Enterprise organization.
I have Copilot Business license managed by my organization.
Copilot Memory is enabled.
I am admin of mentioned repository.

[adityasharad]

Thanks for reporting - we just fixed a bug in this settings page that was affecting the loading of memories for org-owned repos - could you please let us know if you are still seeing this inconsistency?

[filip-be]

Hi @adityasharad! It seems to work well, thanks and apologies for the late reply!

[grahame-student]

We turned on Copilot Memories for our GitHub Enterprise organisation.
We are using Copilot Enterprise licenses, managed by the organisation.
Copilot Memory is enabled.
Copilot code reviews are enabled.
I am an organisation owner.

In the week that we've had the feature enabled, I have yet to see a single memory in the Copilot->Memory settings, for any of the repositories within our organisation.

All I ever see is this message:

[grahame-student]

Typical, 5 mins after posting one of our repos starts forming memories 🙄

Now that I can see something to provide more feedback on...

• Looks promising, the GitHub action related memories are things I've had to repeatedly remind Copilot about in the past. I look forward to never having to do that again in this repo!
• I wasn't expecting to see duplicate memories, without seeing exactly what's stored I guess they might actually have subtly different metadata. I could see this making curating memories a bit tricky.

[tiferet]

Thank you for the feedback!

Looks promising, the GitHub action related memories are things I've had to repeatedly remind Copilot about in the past. I look forward to never having to do that again in this repo!

That's music to my ears -- we really appreciate you sharing this! ❤️

I wasn't expecting to see duplicate memories, without seeing exactly what's stored I guess they might actually have subtly different metadata. I could see this making curating memories a bit tricky.

This is an interesting point! The duplication is by design (see our blog post), though it's just a stop-gap until we implement a more elegant solution for agents to upvote useful memories and refresh their timestamp to indicate that they remain relevant. I can see how it makes curation hard 🤔

[grahame-student]

I wasn't expecting to see duplicate memories, without seeing exactly what's stored I guess they might actually have subtly different metadata. I could see this making curating memories a bit tricky.

This is an interesting point! The duplication is by design (see our blog post), though it's just a stop-gap until we implement a more elegant solution for agents to upvote useful memories and refresh their timestamp to indicate that they remain relevant. I can see how it makes curation hard 🤔

Ahh, I missed the reporting agent tag!

[grahame-student]

Is the long term plan to have memories replace copilot-instructions.md?

My experience shows that the contents of copilot-instructions.md tend to become stale and, after the first run of the coding agent, tends to be ignored / not considered.

For example if I assign a task to the coding agent the first set of changes align closely with the copilot-instructions.md. If I then provide feedback / ask for follow up changes then copilot-instructions.md do not tend to be respected as closely.

[Faizankhan1924]

i want but the pro plan but my id is block when i add my card kindly check and resolve my issue i need to buy for monlty

[rs38]

any plans to provide memory also for local Copilot development?

[filip-be]

@rs38 it's there in the vs code insiders for a while already, and I've also seen this setting option available in stable vs code yesterday :)
https://www.reddit.com/r/GithubCopilot/comments/1oo4ty9/github_copilot_native_memory_tool_is_now/

[rs38]

thx, indeed it's there...

and not the 1st feature well hidden in vscode ;)

once activated it add this to the prompt:

<repoMemory>
If you come across an important fact about the codebase that could help in future code review or generation tasks, beyond the current task, use the memory tool to store it. Facts may be gleaned from the codebase itself or learned from user input or feedback. Such facts might include:
- Conventions, preferences, or best practices specific to this codebase that might be overlooked when inspecting only a limited code sample
- Important information about the structure or logic of the codebase
- Commands for linting, building, or running tests that have been verified through a successful run

<examples>
- "Use ErrKind wrapper for every public API error"
- "Prefer ExpectNoLog helper over silent nil checks in tests"
- "Always use Python typing"
- "Follow the Google JavaScript Style Guide"
- "Use html_escape as a sanitizer to avoid cross site scripting vulnerabilities"
- "The code can be built with `npm run build` and tested with `npm run test`"

</examples>

Only store facts that meet the following criteria:
<factsCriteria>
- Are likely to have actionable implications for a future task
- Are independent of changes you are making as part of your current task, and will remain relevant if your current code isn't merged
- Are unlikely to change over time
- Cannot always be inferred from a limited code sample
- Contain no secrets or sensitive data

</factsCriteria>

Always include the reason and citations fields.
Before storing, ask yourself: Will this help with future coding or code review tasks across the repository? If unsure, skip storing it.

If the user asks how to view or manage their memories, refer them to https://docs.github.com/en/copilot/how-tos/use-copilot-agents/copilot-memory.

</repoMemory>

[OrenMe]

Memories view and manage permission fine grained permissions
For now only repo admin or org/ent admins can view it
Add fine grained permissions for view and for manage/delete

Would be great to at least have it it as part of same as AI controls

[beingminimal]

@ebndev When memories will be editable like jules?