# GitHub Copilot Memory Is a Real Step. It Still Only Knows GitHub URL: https://getunblocked.com/blog/github-agent-memory-only-knows-github/ Published: 2026-11-03T15:10:00Z Author: Brandon Waselnuk Categories: Context Engine, Engineering Insights GitHub Copilot memory is now GA and learns from GitHub data, as over 40% of PRs start with an agent. What it misses, and how teams share context across tools. --- On October 28, 2026, at GitHub Universe, GitHub launched GitHub intelligence. Copilot memory became generally available on paid plans, a new opt-in preview called Dreaming started curating those memories, and Copilot gained code search across repositories. GitHub calls the bundle "the context and learning layer sourced from the graph of GitHub data" in its [launch changelog](https://github.blog/changelog/2026-10-28-github-intelligence-puts-your-code-context-and-history-to-work). GitHub Copilot memory is a real step forward. It also learns only from what GitHub can see, and it only serves Copilot and apps built on the Copilot SDK. If your team also runs Claude Code, Cursor or Codex, you now have one memory per agent, each partial and each going stale on its own schedule. A team context layer that every agent queries closes that gap. ## What did GitHub ship at Universe 2026? GitHub shipped three pieces under one name. The first is memory, now generally available on paid Copilot plans. Copilot remembers personal preferences and repository conventions across sessions and clients, such as the right test command for a repo. Among Copilot CLI sessions GitHub reviewed during the public preview where the agent used memory, 93% showed better adherence to developer preferences and 42% showed more efficient workflows, per [GitHub's changelog](https://github.blog/changelog/2026-10-28-github-intelligence-puts-your-code-context-and-history-to-work). The second is Dreaming. **Copilot Dreaming** is a preview feature that reflects on past Copilot sessions and pull request review feedback, then updates memories and proposes changes to guidance files. Per the [Dreaming docs](https://docs.github.com/en/copilot/concepts/prompting-and-context/copilot-dreaming), it edits memories directly but opens a pull request for any change to `.github/copilot-instructions.md`, `AGENTS.md` or skill files. It is in public preview, opt-in, and every run uses AI credits. The third is cross-repository code search, so Copilot can find code, configuration, schemas and documentation across related projects and dependencies without a local clone. ## Why is GitHub Copilot memory a real step forward? Copilot memory takes the problem seriously, and the design shows it. Repository facts are [shared with collaborators](https://docs.github.com/en/copilot/concepts/agents/copilot-memory), so one person's correction helps the next session. Copilot checks each fact's citations against the current branch before trusting it. Facts that nobody reinforces expire after 90 days by default, and owners can set that window anywhere from 7 to 180 days. Dreaming routes changes to checked-in instructions through a pull request, which keeps a human in the loop for the files that matter most. The timing makes sense too. More than 40% of pull requests in September 2026 started with an agent's first draft, up from 17% in March, according to GitHub's [Octoverse 2026 report](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/). GitHub notes that figure is a floor, since it only counts agents it can detect. When that much code starts with an agent, what it remembers between sessions decides how much rework lands in review. GitHub building memory into the platform shows that agent memory is now part of the stack. ## What can GitHub Copilot memory see, and what can't it? Copilot memory sees what happens on GitHub. The Dreaming docs list what Dreaming draws on when it curates memories: "previously synced sessions, memories, repository content, and pull request review feedback." That covers how code is written far better than why it is that way. Take a retry limit set to three in a payments client. The pull request might say "lower retries per incident review." The incident review, the Slack thread where the on-call engineer argued for three instead of five, and the Jira follow-up all live outside GitHub. An agent asked to "make the client more resilient" may raise the limit back to five. Developers know where that context sits. In the Stack Overflow 2026 survey results, 85% named project goals and requirements as the best source of trusted context, and 72% look to the people they work with for specific answers ([Stack Overflow, 2026](https://stackoverflow.blog/2026/10/06/the-results-of-the-2026-developer-survey-are-here/)). Neither lives in a repository, as we cover in [why was this built this way](https://getunblocked.com/blog/why-was-this-built-this-way/). ## What happens when every agent ships its own memory? Each of the main coding agents now keeps what it learns in its own place. That same week, OpenAI's Codex CLI [release 0.165.0](https://github.com/openai/codex/releases/tag/rust-v0.165.0) made memory v2 the default for fresh memory profiles and added support for importing memories from other agents. Local Codex memories are still [off by default](https://learn.chatgpt.com/docs/customization/memories); once a developer turns them on for a machine, Codex stores them under `~/.codex/memories/` on that machine. Claude Code's auto memory lives in [`~/.claude/projects//memory/`](https://code.claude.com/docs/en/memory), also on the developer's machine. Cursor keeps project rules in `.cursor/rules` and [team rules in its dashboard](https://cursor.com/docs/context/rules). Copilot memory lives in GitHub. Claude Code (66%) and GitHub Copilot (59%) were the two leading agents in [Stack Overflow's 2026 results](https://stackoverflow.blog/2026/10/06/the-results-of-the-2026-developer-survey-are-here/), and a single team can end up on several. At Invoca, for example, roughly half the developers work in Claude Code and the other half in Cursor. **Memory sprawl** is the result: one memory per agent, per machine or per platform, none of which can read the others. Codex's import feature shows vendors feel this too, but an import copies a snapshot from one silo into another and does not keep them in step. A March 2026 paper on [multi-agent memory](https://arxiv.org/abs/2603.10062) calls consistency across agents "the most pressing open challenge" for systems where agents share work. ## How does each agent's memory go stale? Each memory goes stale in its own way, which makes the drift hard to spot. Copilot memory expires repository facts after a period without reinforcement and re-checks citations against the branch. The same Copilot memory docs are candid that facts can come from closed, unmerged pull requests. GitHub says the branch check "does not guarantee that it will recognize every outdated fact." Codex and Claude Code memories change on each laptop, and Cursor team rules change when an admin edits them. Consider a team that renames its `billing-api` service to `payments-core`. Copilot memory can pick up the new name after a few merged PRs. The Codex memory on one engineer's laptop still says `billing-api` until that engineer happens to correct it. A Claude Code session on a third machine never heard of the rename. Three agents give three answers, and the reviewer catches it. That is the predictability problem: the same task gives different output depending on which memory the agent happened to read. Shared memory has its own risks. A June 2026 paper on [governed shared memory](https://arxiv.org/abs/2606.24535) lists stale propagation and contradiction persistence among four failure modes, and concludes that "long-context retrieval alone is insufficient" for production multi-agent memory. A team layer has to resolve conflicts as well as store facts. ## GitHub Copilot memory vs Codex memory vs a team context layer The three approaches differ most in what they can read and who shares the result. This table shows them at a glance, using each vendor's own documentation for its column. | | GitHub Copilot memory | Codex memory | Team context layer | | --- | --- | --- | --- | | What it sees | Copilot sessions, repository content, PR review feedback | Your prior Codex chats on that machine, plus imported memories | Code, PRs, issues, docs, Slack or Teams threads, Datadog and Sentry | | Who shares it | Repo facts: collaborators on that repo; preferences: you | You, on one machine | The whole team, filtered by each person's source permissions where enforced | | Where it runs | GitHub, in Copilot surfaces | \~/.codex on each laptop | A shared service any MCP-capable agent can call, Copilot included | | How it stays current | Citation checks, 90-day default expiry, Dreaming | Local consolidation | Updates from the source systems as they change | | Which agents use it | Copilot | Codex | Copilot, Claude Code, Cursor, Codex and others over MCP | Copilot memory and a team context layer can run side by side. ## Memory layer for Claude Code and Cursor that is shared across an engineering team A memory layer shared across Claude Code and Cursor has to live outside both tools. A **team context layer** is a shared service that reads the systems a team already works in, reconciles what they say, and returns the same permission-filtered answer to any person or agent that asks. It sits behind one [MCP](https://modelcontextprotocol.io/docs/getting-started/intro) endpoint, an open standard supported by Claude, ChatGPT, VS Code, Cursor and many other clients, so every tool queries the same source. Unblocked is the context engine for engineering built this way. It connects GitHub or GitLab, Slack or Teams, Jira, Linear, Confluence, Datadog and Sentry, and it runs in Claude Code, Cursor, Codex, GitHub Copilot (in [VS Code](https://docs.getunblocked.com/unblocked-mcp/install-vscode) and [JetBrains IDEs](https://docs.getunblocked.com/unblocked-mcp/install-jetbrains)) and Windsurf, plus Slack and the web. With [Data Shield](https://docs.getunblocked.com/team-settings/data-shield), answers respect the permissions set in each source system, and it is always on for Slack, so a private channel stays private. You set it up once per agent, not once per source, as shown in [one MCP for Claude Code, Codex and Devin](https://getunblocked.com/blog/one-mcp-for-claude-code-codex-devin/). Invoca's developer enablement team tested this directly. Their test setup was an A/B harness that ran the same task in two isolated agent runs, one with Unblocked and one without, across 20 tasks in several repositories. Median task time was 30% faster and median token spend 40% lower with Unblocked, as the [Invoca story](https://getunblocked.com/customers/invoca/) details. > With AI in general it's garbage in, garbage out. The more consistent that context layer looks between agent runs and between everyone's machines, the more predictable the outputs are when they get to code review. Whether you're in Cursor or Claude Code, it's the same MCP endpoint and the same tool calls. > > — Danny Peck, Principal Engineer, Invoca ## We use Copilot and Claude Code on our repo, what does a context engine add? A context engine adds the reasons that GitHub data alone doesn't hold, and it gives Claude Code the same view of them that the rest of the team has. Keep Copilot memory on. It is good at conventions that show up in code and review, such as a naming pattern or feedback reviewers keep giving. A context engine adds three things around that: - Decisions from outside GitHub. The Slack thread, the Jira epic, the Confluence design doc and the incident timeline behind a change, with citations so the agent can show its work. - One answer across tools. Copilot, Claude Code and Cursor get the same reconciled answer over the same MCP connection, so an engineer on any of them starts from the same facts. - Conflict handling. When the wiki says one thing and last week's thread says another, the engine weighs recency and source to settle it before the agent sees it. Citations matter here: Stack Overflow's survey ties trust in AI output to source attribution, at 93% ([2026 survey](https://stackoverflow.blog/2026/10/06/the-results-of-the-2026-developer-survey-are-here/)). For more, see [what is a context engine](https://getunblocked.com/blog/what-is-a-context-engine/) and our answer on [a context engine vs direct MCPs for GitHub, Confluence and Slack](https://getunblocked.com/answers/context-engine-vs-direct-mcps-github-confluence-slack/). ## What to do this week Start by turning on what GitHub shipped. Enable GitHub Copilot memory for your main repositories and set an expiry window that fits how fast your code changes. Try Dreaming on one repository and read the pull requests it opens against your instruction files. They show what Copilot thinks your conventions are. Next, count your memories. List every agent your team runs and where each one stores what it learns. If the answer includes laptops, you have per-person memory that nobody else can see. Our guide to [keeping CLAUDE.md, AGENTS.md and Cursor rules in sync](https://getunblocked.com/blog/keeping-claude-md-agents-md-cursorrules-in-sync/) covers the checked-in half of that problem. Then pick one recent change where an agent got the reason wrong, for example a reverted config value, and trace where the reason lived. If it was in Slack, Jira or an incident review, that is the case for a shared context layer. Our comparison of [memory MCP servers](https://getunblocked.com/blog/memory-mcp-servers-compared/) and our post on [institutional memory for Claude Code](https://getunblocked.com/blog/claude-code-institutional-memory/) cover the options, from single-user memory servers to a team-wide context engine. ## Frequently asked questions ### Is GitHub Copilot memory shared across a team? Partly. Repository facts are shared with collaborators who have read access to that repository. Personal preferences follow one user between repositories. GitHub's docs describe no organization-wide memory, and facts are not pooled across repositories. ### Can Claude Code or Cursor read Copilot memory? GitHub's documentation lists only Copilot surfaces as users of memory, plus apps built on the Copilot SDK. Claude Code and Cursor keep their own memory and rules. ### Does Codex memory sync across machines? OpenAI's docs describe Codex memory as a local store under `~/.codex` that is off by default and that you turn on per machine, and they recommend keeping required team guidance in `AGENTS.md` or checked-in docs. Release 0.165.0 added importing memories from other agents. ### Do I still need AGENTS.md if I use Copilot memory? Yes. GitHub's own docs say memories don't guarantee a rule is followed and recommend custom instructions for important rules. Checked-in instruction files work across agents, while memory stays inside each tool.