Why does my AI coding agent forget everything between sessions?

Because nothing is saved by default. A coding agent's working memory is the context window, which is rebuilt from scratch each time you start a session. The previous conversation exists as a transcript on disk, but it is not loaded unless you explicitly resume it. Anything the agent worked out last time, such as a decision, a dead end, or a half-finished migration, is gone unless something wrote it to a file it reads on startup.

Does a bigger context window fix it?

No. A bigger window means a single session can hold more before it has to compact, which is a real improvement. But it does not change what happens when that session ends. A one-million-token window that starts empty is still empty. Size is about how long you can go, not about what carries over.

What is the difference between compaction and forgetting?

Compaction happens inside one session: when the context fills up, the older part of the conversation is replaced by a summary so work can continue. It is lossy, and details you never flagged as important are usually what goes. Forgetting between sessions is total: the next session does not even have the summary unless you resumed that specific session.

Can I just paste a summary in at the start of each session?

You can, and it works. It is also the thing people stop doing after about a week, because it has to happen at the exact moment you are least interested in writing documentation, which is the end of a session when the thing you were building finally works. Every durable solution is really a way of removing that moment of discipline.

Is an instruction file like CLAUDE.md enough on its own?

For stable facts, yes, and you should have one regardless. It is the right place for how the project is laid out, how to run the tests, and conventions to follow. It is the wrong place for state, because it is a file you maintain by hand and nothing updates it when work moves on. In practice it goes stale, and a stale instruction file is worse than none because the agent trusts it.

Do I need an MCP memory server?

Only if your problem crosses a boundary the simpler options cannot. An instruction file plus a handoff note in the repo covers a single project on a single machine very well. You want a memory server when you have many projects, or work on more than one machine, or use more than one editor, or want the agent to record state without you remembering to ask.

Does any of this work across different editors?

Instruction files do not. Claude Code reads CLAUDE.md, Codex reads AGENTS.md, Copilot reads .github/copilot-instructions.md, and Cursor reads .cursor/rules. A file in the repo, like a plain HANDOFF.md, works everywhere because it is just a file you tell the agent to read. A remote MCP server also works everywhere, because MCP is the one interface all of these clients share.

What is the smallest thing that actually helps?

A single HANDOFF.md at the root of the repo, and one line in your instruction file telling the agent to read it at the start and update it at the end. It costs nothing, it is versioned with the code, and it survives you changing editors. Start there and add machinery only when you feel it failing.

Why your coding agent forgets everything between sessions

What actually persists, what does not, and the five ways people fix it.

The short answer: nothing is saved by default. An agent's working memory is its context window, and that window is built fresh every time you start a session. The last conversation is still on disk as a transcript, but it is not loaded unless you deliberately resume it. So every decision, dead end and half-finished refactor from yesterday is gone this morning, and the agent confidently starts over.

This is not a bug, and it is not going to be fixed by a bigger model. It is a design property of how these tools work, and the fix is always the same shape: something has to write state down, and something has to read it back at the start of the next session. The five options below differ only in what does the writing, and how much you have to remember.

What persists and what does not

Across Claude Code, Codex CLI, Cursor and Copilot, roughly:

Does not persist: the conversation, anything the agent reasoned out, which files it had read, what it tried and abandoned, why it chose one approach over another.
Persists, but is not read automatically: the session transcript on disk. It is there, and resuming is how you get at it.
Persists and is read automatically: files the client loads on startup by convention, meaning CLAUDE.md for Claude Code, AGENTS.md for Codex, .github/copilot-instructions.md for Copilot and .cursor/rules for Cursor, plus whatever a startup hook or an MCP server hands over.
Persists and is always true: your code and your git history. Worth saying, because a surprising amount of the "memory" people want is just the agent reading the repo properly.

Compaction is a different problem

These get conflated constantly. Compaction happens inside a single long session: the context fills, the older part of the conversation is swapped for a summary, and work continues. It is lossy, and what gets lost is whatever nobody marked as important. Claude Code exposes this as /compact.

Forgetting between sessions is total. A new session does not have the summary either. If you are losing detail mid-session, you want compaction hints and a tighter scope. If you are losing everything overnight, you want one of the five below. They are not the same fix.

The five real fixes

1. Resume the previous session

Best for: picking up where you left off, today

Claude Code has claude --continue for the most recent session and claude --resume to pick one from a list. Codex has codex resume. This restores the actual conversation, so it is the highest-fidelity option there is.

The limits are real, though. It is tied to the machine the transcript is on, it does not help a second editor, and a transcript long enough to be worth resuming is usually long enough that resuming it immediately triggers compaction. Excellent for a lunch break. Not a memory strategy.

2. An instruction file

Best for: stable facts that do not change

CLAUDE.md, AGENTS.md, .github/copilot-instructions.md, .cursor/rules. Loaded automatically at session start. This is the correct home for how the project is laid out, how to run the tests, which conventions to follow, and what never to touch. Claude Code also reads a personal ~/.claude/CLAUDE.md that applies across every project.

Do this one regardless. It is the highest value-per-minute item on this page. But it is a file you maintain by hand, and nothing updates it when the work moves on, so it is the wrong place for current state. In practice it goes stale, and a stale instruction file is worse than no file, because the agent believes it.

3. A handoff file in the repo

Best for: one project, any editor, near-zero setup

A plain HANDOFF.md at the repo root holding what is in flight, what was just decided, and what to do next. Then one line in your instruction file: read it at the start of a session, update it at the end.

This is the smallest thing that genuinely works, and it is more robust than it sounds. It is versioned alongside the code, it survives you switching editors, it is reviewable in a pull request, and a human can read it. Its weakness is that it depends on the agent actually being told to update it, and it lives in one repo, so it has nothing to say about the other eleven.

4. A session-start hook

Best for: making it automatic on your own machine

Claude Code can run a SessionStart hook that injects text into the context before you type anything. Point it at a script that prints your current state, such as the handoff file, open tickets, or the last few commits, and the agent arrives already briefed with nothing for you to remember.

This removes the discipline problem, which is the thing that kills options 2 and 3. The cost is that you are now maintaining a small program, it is configured per machine, and it is specific to clients that support hooks.

5. An MCP memory server

Best for: many projects, many machines, more than one editor

Model Context Protocol is the one interface Claude Code, Codex, Cursor, Copilot and Devin all speak. A memory server exposes reading and writing state as tools, so the agent can fetch a brief at the start and record what happened at the end, on its own, from any client and any machine.

Options range from the official reference memory server, which stores a local knowledge graph, through self-hosted projects, to hosted boards. Astryke Hub is ours, and it is built around per-project state rather than a general fact store. The honest tradeoff is that this is the heaviest option: a service to trust, a connection to configure, and for hosted ones, a bill.

It earns that weight when the simpler options stop reaching. One project on one machine does not need it. Nine projects across a desktop and a laptop, where the question is which one you were even in the middle of, is exactly what it is for.

How to choose, in order

Write an instruction file. Everyone should have one, it takes twenty minutes, and it fixes the most common complaint, which is the agent not knowing how to run your tests.
Add a HANDOFF.md and a line telling the agent to keep it current. Now state survives the session.
If you keep forgetting to have it updated, automate the read with a session-start hook.
If you have outgrown one repo, one machine or one editor, move state to an MCP server.

Most people never need step four, and saying so is more useful than pretending otherwise. If you do reach it, the setup docs cover connecting each client, and CLAUDE.md vs an MCP memory server works through the tradeoff in more detail.

Common questions

Why does my AI coding agent forget everything between sessions?
Because nothing is saved by default. A coding agent's working memory is the context window, which is rebuilt from scratch each time you start a session. The previous conversation exists as a transcript on disk, but it is not loaded unless you explicitly resume it. Anything the agent worked out last time, such as a decision, a dead end, or a half-finished migration, is gone unless something wrote it to a file it reads on startup.
Does a bigger context window fix it?
No. A bigger window means a single session can hold more before it has to compact, which is a real improvement. But it does not change what happens when that session ends. A one-million-token window that starts empty is still empty. Size is about how long you can go, not about what carries over.
What is the difference between compaction and forgetting?
Compaction happens inside one session: when the context fills up, the older part of the conversation is replaced by a summary so work can continue. It is lossy, and details you never flagged as important are usually what goes. Forgetting between sessions is total: the next session does not even have the summary unless you resumed that specific session.
Can I just paste a summary in at the start of each session?
You can, and it works. It is also the thing people stop doing after about a week, because it has to happen at the exact moment you are least interested in writing documentation, which is the end of a session when the thing you were building finally works. Every durable solution is really a way of removing that moment of discipline.
Is an instruction file like CLAUDE.md enough on its own?
For stable facts, yes, and you should have one regardless. It is the right place for how the project is laid out, how to run the tests, and conventions to follow. It is the wrong place for state, because it is a file you maintain by hand and nothing updates it when work moves on. In practice it goes stale, and a stale instruction file is worse than none because the agent trusts it.
Do I need an MCP memory server?
Only if your problem crosses a boundary the simpler options cannot. An instruction file plus a handoff note in the repo covers a single project on a single machine very well. You want a memory server when you have many projects, or work on more than one machine, or use more than one editor, or want the agent to record state without you remembering to ask.
Does any of this work across different editors?
Instruction files do not. Claude Code reads CLAUDE.md, Codex reads AGENTS.md, Copilot reads .github/copilot-instructions.md, and Cursor reads .cursor/rules. A file in the repo, like a plain HANDOFF.md, works everywhere because it is just a file you tell the agent to read. A remote MCP server also works everywhere, because MCP is the one interface all of these clients share.
What is the smallest thing that actually helps?
A single HANDOFF.md at the root of the repo, and one line in your instruction file telling the agent to read it at the start and update it at the end. It costs nothing, it is versioned with the code, and it survives you changing editors. Start there and add machinery only when you feel it failing.

Last updated 2026-09-14.