AI Memory Is Not One Thing — And That's the Problem

Every time you start a new AI session and type "as I mentioned before…" only to realize the AI has no idea what you're talking about — that's a memory problem. And it's one of the most underrated friction points in working with AI tools today.

Memory in AI assistants sounds like a simple feature. The AI remembers stuff. Great. But the moment you dig deeper, you realize that "memory" means completely different things across different tools — and each approach comes with real tradeoffs that affect your day-to-day workflow in ways that aren't always obvious.

This post breaks down how GitHub Copilot, Claude, and ChatGPT handle memory differently, what works, what doesn't, and what you should actually watch out for.

Why Memory Matters More Than You Think

Think about how you work with a teammate. On day one, you explain the codebase, your conventions, your quirks. By month two, they just know. You don't re-explain that the project uses tabs not spaces, or that the API always returns dates in ISO format, or that you never merge on Fridays.

AI tools today are mostly stuck at day one — every session. You re-explain. You re-establish context. You repeat yourself. The cost of this is invisible because each individual instance feels minor, but across days and weeks of daily use it adds up to a meaningful drag on productivity.

The tools have noticed. Almost every major AI coding assistant has shipped some form of memory in the past year. But not all memory is the same.

The Three Types of Memory That Actually Matter

Before diving into specific tools, it helps to have a mental model. Memory in AI tools generally falls into three categories:

User memory stores personal preferences and habits — things like coding style, preferred frameworks, how you like responses formatted. It follows you across all projects.

Session memory is the context within a single conversation — what you've said, what the AI has done, the state of the current task. It lives only as long as the session does.

Project/repo memory stores knowledge about a specific codebase — its architecture, conventions, dependencies, quirks. It's shared across sessions and potentially across team members working on the same repo.

Most tools have all three in some form. The difference is in how they're stored, who updates them, and how reliably they're actually used.

GitHub Copilot: The Most Layered Memory System

GitHub Copilot Chat in VS Code has arguably the most structured memory architecture of any coding assistant right now. It has a dedicated memory tool with three distinct scopes — user, session, and repository — plus a separate instruction files system that's often conflated with memory but serves a different purpose.

The Three Memory Scopes (VS Code Copilot Chat Agent Mode)

These three memory tiers are part of Copilot Chat's agent mode in VS Code. They're managed through a built-in memory tool that can create, read, update, and delete memory entries stored as files.

User Memory (/memories/)

User memory stores persistent notes that survive across all workspaces and conversations. Think of it as your personal knowledge base that Copilot carries with you — common commands, debugging strategies, coding preferences, lessons learned across projects. The first 200 lines are automatically loaded into the agent's context at the start of every conversation.

These are stored locally in VS Code's user data directory (not in the cloud), specifically at:

• Windows: %APPDATA%\Code\User\globalStorage\github.copilot-chat\memory-tool\memories\
• macOS: ~/Library/Application Support/Code/User/globalStorage/github.copilot-chat/memory-tool/memories/
• Linux: ~/.config/Code/User/globalStorage/github.copilot-chat/memory-tool/memories/

They're organized as markdown files by topic — you might have debugging.md, patterns.md, common-commands.md, etc. Copilot's agent can both read and write to user memory — it might note a tricky build command you discovered, or record a debugging pattern that worked. You can also navigate to these files and edit them directly in any text editor.

One important boundary: session context does not automatically flow into user memory. Your terminal commands, file edits, error messages, and task-specific work stay in the conversation context and are discarded when the session ends. The agent only writes to user memory when it judges something as a reusable insight — or when you explicitly ask it to remember something. This is by design (you don't want every debug session cluttering your permanent memory), but it means you need to be intentional about telling Copilot "remember this" when you discover something worth keeping.

Another real friction point: the 200-line auto-load can conflict with your current work. Because user memory is injected at the start of every session, stale or outdated entries can actively fight you. If your memory says "build command is X" but you've since changed your approach, the agent may defer to its loaded memory over your live correction — essentially arguing with you based on outdated notes. This is particularly frustrating when you're iterating on a workflow and the agent keeps reverting to a pattern you've already moved past. The practical fix is to regularly audit and prune your user memory files, treating them like living documentation rather than write-once notes.

Session Memory (/memories/session/)

Session memory is scoped to the current conversation. Unlike the basic context window (which is just the chat history), session memory is a set of explicitly managed files where the agent stores task-specific context — plans, progress notes, intermediate findings. The agent can create files, update them as work progresses, and reference them throughout the conversation. Session memory is cleared when the conversation ends.

This is more structured than just "what's in the chat history." It gives the agent a scratchpad for complex multi-step tasks where tracking state matters.

Repository Memory (/memories/repo/)

Repository memory stores facts about the specific codebase — conventions, architecture decisions, verified build commands, cross-file dependencies. From VS Code Chat, only the create command is supported (the agent can store facts but retrieval is handled by the cloud platform). Each fact is stored as a JSON object with structured fields: subject, fact, citations, reason, and category.

Copilot Memory (The Cloud Platform)

To be clear: Repository Memory and Copilot Memory are the same thing, just viewed from different angles. When the VS Code Chat agent writes a fact to /memories/repo/, that fact becomes a Copilot Memory entry stored in the cloud and scoped to the repository. "Repository memory" is the local write path; "Copilot Memory" is the cloud platform that stores, validates, and serves those memories across all Copilot features. They're not two separate systems — they're two ends of the same pipe.

Memories created by any part of Copilot — VS Code Chat agent, Copilot cloud agent, or Copilot CLI — are stored in the cloud and scoped to the repository.

A few things make this notable:

It's cross-agent. What the coding agent learns, the code review agent can use. If Copilot cloud agent figures out how your project handles authentication, Copilot code review will apply that understanding when reviewing a PR that touches auth code. Currently, Copilot Memory is used by Copilot cloud agent, Copilot code review (on PRs), and Copilot CLI.

It's validated before use — but it's a heuristic, not a guarantee. Each memory stores citations — references to specific code locations that support it. Before a memory is used, Copilot checks those citations against the current codebase and current branch. If the code has diverged significantly — say, a teammate merged changes that deleted or heavily refactored the code a memory references — the citations won't match, and the memory is discarded rather than applied. This catches the most common staleness problem: memories that reference code that no longer exists.

Where it gets murkier is subtle drift — renamed variables, shifted line numbers, restructured logic that still partially matches the original citations. In these cases, the citation check may pass even though the underlying fact is no longer accurate. It's a best-effort filter, not a proof system. Good enough to prevent most stale knowledge from leaking in, but not something you should blindly trust for every memory Copilot applies.

It expires. Memories have a 28-day lifespan. This is a deliberate design choice — codebases change, and what was true three months ago may not be true today. If a memory is validated and reused, a new memory with the same details is stored, effectively extending its life.

It's shared across the team. Copilot Memory is repository-scoped, not user-scoped. Everyone with access to the repo — and with Copilot Memory enabled — benefits from the same accumulated knowledge. A new team member gets an AI that already understands your codebase.

Who can write memories? Only users with write permission to the repository, and only when Copilot Memory is enabled for that user. Memories are created in response to Copilot activity initiated by those users — you can't create memories in a repo you only have read access to. Who can manage them? Repository owners can view and delete stored memories through GitHub repository settings (Settings → Copilot → Memory). Individual contributors can't view the memory list directly — only repo owners get that admin view.

Copilot Memory is on by default for Pro and Pro+ users. For enterprise and organization plans, it's turned off by default and must be enabled by admins.

How Copilot Memory Works with Code Review and Cloud Agents

The cross-agent sharing mentioned above deserves a closer look, because it's where Copilot Memory delivers the most practical value. Currently, three Copilot features consume and create memories:

Copilot Cloud Agent (the one that works on GitHub issues and PRs autonomously) is the primary memory producer. As it explores your codebase, builds your project, runs tests, and submits PRs, it picks up patterns — how your project structures database access, which config files need to stay in sync, what naming conventions your team uses. These get written as memories. The next time the cloud agent picks up an issue in the same repo, it starts with that accumulated context rather than rediscovering everything from scratch.

Copilot Code Review is the most compelling consumer. When you open a PR, Copilot code review checks the diff against stored memories. If the cloud agent previously learned that "settings in appsettings.json and config.yaml must stay synchronized," code review will flag a PR that updates one but not the other. If a memory records that "all public API methods must validate input parameters," code review will catch a new endpoint that skips validation. This is powerful because code review feedback becomes repository-aware rather than generic — it reflects knowledge specific to your codebase.

Copilot CLI also participates. Commands run through Copilot CLI can both create and consume memories, so knowledge flows between terminal-based workflows and PR-based workflows.

The cross-agent loop is what makes this genuinely useful: the cloud agent learns by doing work → those learnings become memories → code review applies those learnings to catch issues in human-authored PRs → and the cycle compounds over time. A team that's been using Copilot Memory for a few weeks gets meaningfully better code review feedback than one that just enabled it.

Instruction Files: The Other System

It's important to distinguish memory from instruction files — a separate customization system that's often confused with memory:

• .github/copilot-instructions.md — always-on project instructions loaded into every Copilot Chat session. Think of this as a README for the AI.
• AGENTS.md — folder-scoped instructions that apply when the agent is working in that directory.
• .instructions.md files — file-pattern-scoped instructions (e.g., apply React patterns only to .tsx files).

Instruction files are deterministic, version-controlled, and always loaded. Memory is probabilistic, auto-curated, and validated at use time. For hard rules your team must follow ("always use Python typing," "never merge on Fridays"), use instruction files. For accumulated knowledge that evolves ("this service talks to Redis for caching," "the build requires Node 20"), memory is the right tool.

The Real Tradeoff

The layered system is powerful but has a learning curve. New users often don't realize they have three separate memory scopes plus instruction files, and may put information in the wrong place. The practical guidance:

• Must-follow rules → instruction files (.github/copilot-instructions.md)
• Personal workflow notes → user memory (/memories/)
• Task progress tracking → session memory (/memories/session/)
• Codebase facts others should benefit from → repository memory (/memories/repo/)

Claude: Memory as a Layered File System

Claude takes a fundamentally different approach. Rather than abstract "memories" stored in a cloud database, Claude Code uses a hierarchy of plain markdown files that are read at session start. What you see is what gets injected.

Claude.ai Chat Memory

For Claude in the browser/app, memory works via two tools the model can invoke: one to search past conversations, and one to maintain a synthesized summary of key facts about you. The summary is rebuilt roughly every 24 hours and gets injected into future sessions.

Unlike ChatGPT, Claude doesn't preload memory into every prompt automatically. It retrieves context on demand when it determines it's relevant. This makes it more surgical — but also means it can occasionally miss context it should have caught.

As of March 2026, this chat memory is available to all Claude users including the free tier.

Claude Code Memory (CLAUDE.md)

For developers using Claude Code (the CLI and IDE extension), memory is built around CLAUDE.md files — markdown files that Claude reads at the start of every session. There's a hierarchy:

• Global user memory at ~/.claude/CLAUDE.md — applies to every project. Your personal preferences and cross-project habits go here.
• Project memory at the repo root CLAUDE.md — applies to everyone working on that project. Architecture decisions, build commands, conventions, things a new contributor needs to know.
• Local memory at .claude/CLAUDE.md — personal to your machine, not checked in. Your local setup quirks that shouldn't affect teammates.

What makes this powerful is the auto-memory feature. Claude doesn't just read these files — it writes back to them. As you work, Claude decides what's worth remembering (build commands, debugging patterns, architecture notes, code style preferences) and adds entries to the appropriate file. It uses its own judgment about what's worth keeping. You can review and edit these files anytime.

This is transparent in a way that most memory systems aren't. You can open CLAUDE.md and read exactly what Claude knows about your project. You can edit it, delete entries, or add your own. There's no opaque database somewhere that you can't inspect.

ChatGPT: The Always-On Profile

ChatGPT takes the most aggressive approach to memory. Rather than retrieving context on demand like Claude, or validating against source code like Copilot, ChatGPT builds a user profile that gets injected at the start of every conversation automatically — whether or not it's relevant.

The upside is that it feels seamless. ChatGPT just knows things about you without you having to ask. The downside is less control. Users who do a lot of varied work sometimes find that memories from one project bleed into another, or that preferences saved for one context create noise in a completely different one.

ChatGPT's memory also tends to be more personal and conversational — it remembers your name, your job, your projects, things you've mentioned in passing. Claude's memory by contrast is more professional and task-oriented — it focuses on how you work rather than who you are.

How They Compare

The Bigger Picture: Different Philosophies

Looking across these tools, three distinct philosophies emerge.

Copilot treats memory as a layered infrastructure problem. It separates personal preferences (local user memory), task state (session memory), and shared team knowledge (cloud repo memory) into distinct scopes with different lifetimes and visibility. On top of that, it has a separate instruction files system for deterministic rules. This is the most structured approach — but also the most complex to understand. The most powerful memory it has is the cloud-hosted Copilot Memory: shared, repository-scoped, cross-agent, and citation-validated.

Claude treats memory as a transparency problem. By storing everything in editable markdown files, it makes memory inspectable and controllable. You always know exactly what Claude knows. The tradeoff is it requires a bit more manual curation — though auto-memory is closing that gap.

ChatGPT treats memory as a personalization problem. The goal is to make the AI feel like it knows you, reducing the cold-start friction of every new conversation. It works well for individuals with consistent workflows, but can feel noisy for people who do varied work.

None of these is wrong. They reflect different assumptions about what memory is for.

What Developers Should Actually Do

A few practical takeaways from all of this:

Use the right Copilot memory scope for the right purpose. Hard rules go in instruction files (.github/copilot-instructions.md), personal workflow knowledge in user memory (/memories/), task progress in session memory, and codebase facts in repo memory. Don't dump everything into one place.

Enable Copilot Memory and let it build over time. The repository memory gets more useful the longer it runs. Cross-agent sharing means everything the coding agent learns benefits code review too — that's genuinely valuable for team workflows. Remember it requires write access to the repo.

Treat CLAUDE.md like documentation — because it is. A well-maintained CLAUDE.md is project knowledge that helps both AI and human new contributors get up to speed. Let Claude auto-populate it, but audit it regularly.

Start sessions with a context reminder when something isn't working. If you need Copilot to apply specific knowledge, a brief reminder at the start of a session helps. User memory auto-loads the first 200 lines, but explicitly referencing what you need can improve consistency.

Understand what expires. Copilot repo memories expire after 28 days. Claude and ChatGPT memories don't. Factor this in for long-running projects.

Where This Is Going

Memory in AI coding tools is still early. The problems today — inconsistent application, lack of cross-tool portability, tension between personal and shared memory — are engineering problems with known solutions. The 28-day expiry in Copilot is a hint that teams are still figuring out the right defaults.

What's clear is the direction: AI tools that know your codebase, your conventions, and your preferences — and don't make you re-explain them every session — are demonstrably more useful. The tools that get memory right will feel less like assistants and more like experienced teammates.

We're not there yet. But we're closer than we were six months ago.

Have thoughts on how you manage memory across your AI tools? What's working, what's not?