A developer opens their coding agent on Monday morning and starts explaining the same thing they explained the previous Thursday: why the auth module is split the way it is, which service owns the user table, why the team ripped out the old caching layer in March. The agent goes along with it, writes reasonable code, and by the next session has forgotten most of it. That is not a glitch. It is close to how several of these tools are actually built, and the exact mechanism behind it differs more between products than most developers assume.
"Does it remember my codebase" is three separate questions bundled into one. Does it keep instructions you wrote down. Does it keep a searchable index of your files. Does it keep a record of decisions from a past session, the kind a human teammate would recall unprompted. Claude Code, Cursor, and GitHub Copilot answer those three questions differently, and the answers come from each vendor's own documentation, not from guesswork about what a model probably does under the hood. The short version: none of the three keep a narrative memory of why a past decision was made. Claude Code reloads markdown files from local disk, both developer-written instructions and the notes it saved itself; Cursor's agent searches the live codebase on each request; and GitHub Copilot checks a semantic index built once and refreshed in the background.
What 'Remembering a Codebase' Actually Means
A large language model has no memory of its own between API calls. Everything it appears to know in a session comes from what gets placed into its context window for that specific request. So when a product claims to remember a codebase, it is describing one of three distinct engineering choices: a persistent instructions file reloaded at the start of each session, a background index of the code searched on demand, or an agent that re-reads files live through tools like grep and file search every time it needs them. Most tools combine more than one of these, and which combination a given product uses changes what survives when you close the session and come back tomorrow.
None of the three approaches gives a coding agent a narrative memory of why your team made a specific architectural call last quarter, unless something (a file, an index entry, a note) was written down to carry that reasoning forward. That distinction matters more on a large proprietary codebase than a small one, because the cost of re-establishing context scales with how much there is to explain.
Claude Code: Fresh Context Window, Written Memory
Anthropic's own documentation states it directly: "Each Claude Code session begins with a fresh context window." Nothing about your previous conversation carries over automatically. What does carry over are two separate, deliberately plain-text mechanisms the docs describe as complementary.
- CLAUDE.md files: instructions a developer writes by hand, covering build commands, conventions, and architecture notes. These are read fresh from disk at the start of every session, not stored as a model memory.
- Auto memory: short notes Claude writes itself from corrections and preferences during a session, saved as markdown files in a per-project directory on the local machine. The docs specify this storage is machine-local: "Files are not shared across machines or cloud environments."
- Only the first 200 lines or 25KB of the auto-memory index file load automatically at session start. Everything past that threshold, and any topic file beyond the index, is read on demand through Claude's normal file tools, the same way it reads any other file in the repository.
The practical effect is that Claude Code does not keep a standing vector index of your source files tied to a project. What persists is whatever a developer wrote in CLAUDE.md or Claude itself saved in its auto-memory notes, both in ordinary markdown. Claude re-explores the source code itself live every session through file-reading and search tools, governed by whatever instructions happen to be sitting on disk that day. Delete the memory folder, and the codebase understanding resets to zero except for what is explicitly documented in CLAUDE.md.
Cursor: Live Agent Search, Server-Side Processing
Cursor's current support documentation describes its agent finding relevant files the same way a developer would skim a project: "If you're not sure which files matter, skip it, Agent finds relevant files through its own search." That is a live search over your working directory at the moment you ask, not a retrieval from a memory of a prior conversation.
Cursor's privacy documentation covers what happens to the code and prompts involved in that search, stating plainly: "When you use AI features, Cursor sends prompts and code context to model providers like OpenAI, Anthropic, and Google." That is a server round trip on every relevant request, by design, since the underlying model call has to happen somewhere.
On storage, Cursor's own data-use page distinguishes two states. With Privacy Mode off, the page says Cursor "may use and store codebase data, prompts, editor actions, code snippets" to improve its AI features. With Privacy Mode on, "Customer Data will not be used for training by Cursor." The same page describes file caching as temporary: contents are "encrypted using unique client-generated keys" and cached contents are "never permanently stored." Cursor's enterprise privacy documentation adds one narrower exception: "Cloud Agents are the only feature that requires Cursor to store code."
What Cursor's current public pages do not spell out is exactly how long any intermediate index or cached representation of your files persists between sessions on their servers, at least not with the architecture detail an older documentation set once gave. The honest answer, based only on what the live pages confirm, is: code context leaves your machine on each relevant request, caching is described as temporary and encrypted, and a persistent stored copy is called out specifically for one feature, Cloud Agents, not for ordinary chat or agent use.
GitHub Copilot: One Index Built Remotely, One Built Locally
Visual Studio Code's own documentation describes Copilot maintaining "a semantic index for any workspace automatically," but the location of that index depends entirely on where the repository lives. For a repository hosted on GitHub.com or GitHub Enterprise Cloud, GitHub itself builds and maintains the index remotely, and the docs are specific about the lifecycle: "This index only needs to be built once per repository," after which GitHub updates it "when needed."
For a local folder that is not GitHub-hosted, the behavior flips: Copilot builds the index itself on your machine. The initial build "can take a few minutes," and after that the index is "kept up to date in the background" rather than rebuilt from scratch on every session. The docs also note this local indexing is on by default for personal accounts but off by default for organization and enterprise accounts, and that "parts of the index might be stored on your machine and parts might come from remote sources."
GitHub's own changelog on the semantic indexing rollout confirms this runs automatically rather than on request: indexing is "automatically triggered when you open GitHub Copilot Chat on github.com," and a build that used to take roughly five minutes now usually finishes within seconds, applying to every Copilot plan including the free tier. The index powers the #codebase semantic search, which finds code by meaning rather than exact text. Grep-based search, by contrast, works without any index at all, matching exact text or regex patterns directly against your files.
For a large proprietary codebase hosted on GitHub, the practical consequence is that the persistent artifact is a semantic index built once and incrementally refreshed, not something re-uploaded from scratch each session. That is a meaningfully different cost profile from a tool that re-reads files live every time, but it also means the index itself, not a markdown file you can open and read, is the thing carrying context forward.
Session Memory at a Glance
| What happens | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| What loads automatically at session start | A fresh context window, plus CLAUDE.md files and the first 200 lines or 25KB of auto memory read from local disk | The agent's own live file search of the current codebase | Your prompt, plus matches pulled from a semantic index built earlier for that workspace |
| Where source code is read from | Read live from local disk each session using file and search tools | Read live from local disk through the agent's own search | A pre-built index, GitHub-hosted or local, with grep as a fallback when no index exists |
| What persists without any action from you | Auto-memory notes Claude wrote itself, saved as local markdown files | Whatever Cursor caches or stores server-side; current docs do not describe a narrative memory of past sessions | The semantic index itself, refreshed incrementally rather than rebuilt from scratch |
| Does code leave your machine to build this | No index to build; only prompt context sent to the model leaves the machine | Yes, prompts and code context are sent to model providers on each relevant request | Yes for GitHub-hosted repos, where GitHub builds the index remotely; local workspaces build part of it on-machine |
| Who controls whether it keeps your code afterward | You, by editing or deleting the local memory folder or toggling auto memory off | Privacy Mode: on means Cursor states the data is not used for training | An organization admin setting, on by default for personal accounts, off by default for organizations |
The Real Cost on a Large, Proprietary Codebase
On a small side project, none of this matters much. On a codebase with hundreds of thousands of lines and a handful of services nobody has fully mapped, the mechanism a tool uses changes two things: how much a new session costs before it is useful, and how stale its picture of the code gets between visits. A tool that re-reads files live pays a time cost on each session to rediscover structure, offset by never being stale, since it is always looking at the current file on disk. A tool that leans on a background index pays that cost once, up front, but then depends on how quickly the index catches up after a large refactor or a fast-moving branch.
The pattern across all three vendors' own docs is that none of them promise a session that already knows last quarter's reasoning. Claude Code gets closest by giving you a place, CLAUDE.md and auto memory, to write that reasoning down once so it reloads automatically. Cursor and Copilot lean more on re-discovering structure through search and indexing than on recalling a narrative of past decisions. Whichever tool a team uses, the architectural reasoning that never gets written into a file or a persistent note is the part that has to be re-explained, every time, by a person.
The Privacy Question Worth Asking Before You Point a Tool at Private Code
The memory question and the privacy question are the same question asked from two angles. Anything that lets a tool "remember" code across sessions (a cached file, an index entry, a note) has to be stored somewhere, even temporarily, and that somewhere is either your machine or a vendor's servers. For a proprietary codebase under an NDA or a client contract, where that storage happens and for how long matters more than whether the completions feel smart.
- Does building or using the memory mechanism send your code off your machine, and to which providers? Cursor's own docs confirm prompts and code context go to model providers on each relevant request. Copilot's remote index means GitHub holds a semantic representation of GitHub-hosted repositories.
- Is what gets stored a cache or a permanent copy? Cursor describes file caching as temporary and encrypted, with Cloud Agents called out as the one feature that requires a stored copy of code. Confirm the equivalent detail for whichever specific feature you use.
- Is there an organization-level switch, and do you know its default? Copilot's local-workspace indexing is on by default for personal accounts and off by default for organizations, which means the same feature behaves differently depending on which kind of account opens the editor.
- Does a training opt-out exist, and is it the default or something you have to find? A privacy mode that stops training on your code is not the same as a mode that stops the code from being processed or transmitted at all.
Treat "it remembers my codebase" and "it sends my codebase somewhere" as two separate claims to check against the vendor's own current docs, not one feature to accept on faith.
These tools are still worth using. Read the page describing the specific feature you turn on, since the answer changes by product and sometimes by account type on the same product. The pattern across Claude Code, Cursor, and Copilot is that remembering code and processing it elsewhere turn out to be the same mechanism, described from different angles in different parts of the documentation.
The re-explaining problem is not unique to code. Switching between ChatGPT, Claude, and Gemini for anything, not just a repository, means repeating the same context every time, because each one keeps its own separate memory and none of them read from the others. MemX (memx.app) is built for that broader version of the same problem: it is a memory layer that recalls what a person has explained across ChatGPT, Claude, Gemini, and their own documents, built private by architecture with per-user isolation and encryption at rest. It does not index a codebase, read a repository, or replace what Claude Code's auto memory or Copilot's semantic index do inside an editor. It stops a person from re-typing the same project background, the same client context, the same personal preferences, into a fresh chat every time they switch tools or start a new conversation. For the architectural reasoning a team already keeps in CLAUDE.md or a wiki, a code-aware tool is still the right place for it. For everything a developer explains in conversation and would otherwise retype from memory, a general memory layer is solving an adjacent version of the same problem.
01Does Claude Code remember my codebase between sessions?
Not as a stored index. Each session starts with a fresh context window. What carries over is CLAUDE.md, which you write, and auto memory, short notes Claude saves to local disk. The code itself is re-read live from files every session.
02Does Cursor remember my codebase between sessions?
Cursor's agent searches your files live rather than replaying a saved memory. Its own docs confirm prompts and code context are sent to model providers on each relevant request, with file caching described as temporary and encrypted.
03Does GitHub Copilot remember my codebase between sessions?
Yes, as a semantic index rather than a narrative memory. For a GitHub-hosted repository, GitHub builds the index once and updates it as needed. For a local folder, Copilot builds it once in the background, then keeps it current instead of starting over.
04Is my proprietary code sent to a server when these tools index or search it?
Claude Code reads files locally and sends only prompt context to the model. Cursor and GitHub-hosted Copilot both involve server-side processing, so check each product's current privacy page before using either on closed-source code.
05Why do I keep re-explaining the same architecture decisions to my coding agent?
Because none of these tools default to a running memory of past reasoning. They reload a file you wrote or re-search the current code, not what you explained last week. Writing that reasoning down somewhere persistent is still a manual step.
