Cursor Memory Between Sessions: How to Keep Context
Cursor does not carry a conversation from one chat into the next. Each new Agent chat starts with only what you give it: your rules, your open files, and whatever it reads from the repo. To get memory between sessions, you write the context down where Cursor loads it every time. That means project rules, an AGENTS.md file, or notes it can reach through an MCP server.
That sounds like extra work, and it is a little. But context you write down once stops getting lost when a chat ends. A written version is also easier to check and fix than anything a tool decides to remember on its own.
Does Cursor remember previous chats?
Not in the way people hope. Cursor keeps your chat history so you can scroll back and reopen an old thread, but a fresh chat does not read those old threads. Cursor’s own rules documentation puts the reason plainly: large language models don’t retain memory between completions, so rules exist to supply persistent context at the prompt level.
Say you start a new chat on Monday. The model doesn’t know you decided on Friday to drop the old auth library, or that the billing folder is off limits until the refactor lands. Unless that decision lives somewhere Cursor loads, you will explain it again.
What carries over between Cursor sessions?
Here is what Cursor reads at the start of a session, and what each option is good for. The rule types and locations come from the Cursor rules docs.
| Mechanism | Where it lives | Who sees it | Best for |
|---|---|---|---|
| Project rules | .cursor/rules/ in the repo |
Everyone who clones the repo | Code conventions, architecture, “never do X” |
AGENTS.md |
Repo root or any subfolder | Everyone, and other agents that read it | Plain instructions with no setup |
| User rules | Cursor settings | Only you, in every project | Your personal style and preferences |
| Team rules | Cursor dashboard (Team and Enterprise plans) | Your whole team | Org-wide standards |
| Notes over MCP | An external notes server | Any AI connected to it | Decisions, research, context that spans tools |
| Plain files in the repo | docs/, NOTES.md, ADRs |
Anyone who opens them | Long-form decisions and history |
Cursor loads the first four on its own. The last two are read when the agent goes looking, or when you point it at them.
How do you set up project rules so Cursor remembers?
Project rules are files in .cursor/rules/. Each one can carry frontmatter that controls when it applies. Per the docs, a rule can apply always, or when the agent decides its description matches the task. It can also apply when a matching file is in context, or only when you @-mention it.
A practical starting set for most repos:
- One always-on rule with the stack, the folder layout, and the three or four conventions that matter most. Keep it short, because it is loaded into every chat.
- Glob rules per area, for example one for
app/models/**and one for the frontend, so the agent only reads them when it works there. - Manual rules for rare jobs like migrations or release steps, which you call with an @-mention.
The trap is putting everything in the always-on rule. Every line there is sent with every request and takes space in the context window, whether the task needs it or not.
What should go in AGENTS.md instead of a rule?
AGENTS.md is plain Markdown with no frontmatter. Cursor reads it in the project root and in subfolders, and nested files combine with the parent, with the more specific one winning. It is the simplest option, and other coding agents read the same file, which helps if your team uses more than one tool.
A good split:
AGENTS.mdfor the build and test commands, and the rules a new contributor would need on day one..cursor/rules/for Cursor-specific scoping, when you want a rule to load only for certain files.
If you only want one, start with AGENTS.md. You can move pieces into scoped rules when it grows past a few screens.
How do you hand off context from one session to the next?
Rules hold the stable stuff. The part that changes daily, like what you tried and what comes next, needs a different home. A short handoff note at the end of each session works well:
## Session 2026-10-10: invoice export
Done: CSV export behind a feature flag, tests passing.
Tried: streaming the response; broke on Safari, reverted.
Next: add the date filter, then remove the flag.
Decisions: amounts stay in cents until the view layer.
Ask the agent to write this note before you close the chat, and to read the latest one when you open the next. You can keep these notes in a notes/ folder in the repo. If they hold client details or research that don’t belong in version control, keep them outside it.
The format matters less than the habit. Dates in the heading make it easy to find the latest, and a “Decisions” line keeps choices from being argued again next week.
Can Cursor share memory with Claude or ChatGPT?
Rules and AGENTS.md only help inside your coding tools. If you plan in Claude, research in ChatGPT and build in Cursor, each tool still starts blank about what happened in the others.
The way to bridge them is MCP, the Model Context Protocol. Cursor supports MCP servers, and so do Claude and ChatGPT through connectors. Connect all three to the same notes server and a decision saved from one tool can be searched and read from the others. There is a longer walkthrough in how to share memory between Claude and ChatGPT, and the general setup is covered in MCP server for notes.
Keep the split clean, though. Code conventions belong in the repo, next to the code they describe. Product decisions and client context can live in the shared notes, where every AI can reach them.
How much context should you give Cursor at the start of a session?
Less than you think. A long always-on rule plus a pasted wall of notes leaves less room for the code the agent needs to read. A good default:
- The always-on rule or root
AGENTS.md, kept under a page. - The latest handoff note for the area you’re working on.
- The specific files for the task.
If the agent needs more, it can search. That is the point of keeping notes in a searchable place instead of pasting them in.
For the same idea applied to chat assistants, see Claude memory vs ChatGPT memory.
FAQ
Does Cursor have a memories feature?
Cursor’s current documentation describes rules as the way to keep context between chats, and older links to a memories page now lead to the rules docs. Treat rules, AGENTS.md and your own notes as the reliable options.
Is .cursorrules still supported?
The single .cursorrules file still works but is deprecated. Cursor recommends project rules in .cursor/rules/ or an AGENTS.md file instead.
Where should I keep notes that aren’t about code?
Outside the repo is usually better: client details, research and product decisions don’t need to be in version control. A notes app your AI can reach over MCP lets Cursor read them when it needs to.
Do user rules apply to every project?
Yes. User rules live in Cursor’s settings and apply to Agent chats across all your projects. They are a good place for personal preferences, not project facts.
Where Valta fits
Valta is a hosted vault of Markdown notes with an MCP server. You connect your coding tool and your chat assistants to the same vault, and each of them can save and search notes there. When an AI saves a session note, Valta returns related notes so it can add [[links]]. The next session can find that note from any connected tool. Repo rules stay in the repo; Valta holds the context that spans tools and projects. The setup steps are in connecting Valta to Claude, ChatGPT and Cursor.
The Free plan includes one vault and 100 notes, enough to try the handoff habit for a few weeks. Create a free account.