MemoryRouter
All posts

Does Cursor Remember Past Conversations? Cursor Memory in 2026

John Rood··6 min read

Does Cursor AI track memory across conversations?

No. Cursor does not carry what you said in one chat into the next. It had a Memories feature, and Cursor intentionally removed it starting in version 2.1 (November 2025). Today a new chat starts from your Rules and AGENTS.md. To reuse an earlier conversation you pull it in by hand with @Chats, or you connect an external memory over MCP.

Checked against Cursor's own docs and forum on September 29, 2026:

What persists in Cursor Carries across chats? Notes
Project Rules (.cursor/rules), User Rules, Team Rules Yes, as instructions You write them. Cursor's docs: models "don't retain memory between completions" and rules add persistent context at the prompt level.
AGENTS.md Yes, as instructions Plain markdown alternative to rules.
Memories No, removed Removed starting in 2.1. Staff pointed users to export old memories into Rules.
@Chats Only when you ask Pulls context from one previous conversation into the current prompt.
Conversation search (3.11) Search only Finds past agent transcripts. Nothing is injected on its own.
Automation memories Per automation Cloud automations can keep notes across their own runs. They do not reach your editor chats.
MemoryRouter over MCP Yes, across chats and tools Recall and save from a vault that Claude Code, Codex, ChatGPT and Claude also read.

Sources: Cursor rules docs, Cursor staff on the forum: Memories removed starting in 2.1, @Chats in the prompting docs, Cursor 3.11 changelog, Automations docs.

Cursor removed Memories: what to use instead

If your old memories vanished after an update, that was the 2.1 change, not a bug. Cursor's suggested path is a one-time export into Rules, which turns them into static instructions. That works for standing preferences. It does not capture anything new, and it does not help with the part people actually miss: last week's decision and the reason behind it.

Split the job the way the tools are built:

  • Rules and AGENTS.md for how code should be written. Short, stable, versioned with the repo. See Cursor rules vs memory for the split.
  • @Chats when you remember exactly which thread had the answer.
  • A memory layer for what happened: decisions, rejected approaches, constraints found mid-task. That is the rest of this post.

If Cursor is one of several tools you use, the coding tool memory table shows what Claude Code, Codex, Windsurf and the rest remember natively, and the Cursor memory guide goes deeper on what a chat loses.

Why a new chat starts cold

Somewhere in last week's Cursor chat is the reason you rejected the obvious approach. Your code kept the outcome. The chat kept the reasoning, right up until you closed the tab.

So every new Agent chat starts from zero. It asks solid questions, proposes options you already eliminated, and waits while you reconstruct last week out loud. Each reconstruction is small enough to ignore, which is exactly why it compounds.

The connection is one JSON entry

Cursor speaks the Model Context Protocol, including remote servers with OAuth built in. MemoryRouter runs a remote MCP server, so the whole connection is a single entry in mcp.json, scoped globally or per project:

{
  "mcpServers": {
    "memoryrouter": {
      "url": "https://mcp.memoryrouter.ai/mcp"
    }
  }
}

Use ~/.cursor/mcp.json for global scope, or .cursor/mcp.json inside a project. Enable the server under Cursor Settings > MCP and a browser tab handles sign-in. You pick which vault the connection uses while authorizing, and no API key goes into the config, so there is nothing in the repo for anyone to copy. Connections start read-only by default, the write scope gets requested only when something needs saving, and access can be revoked from your dashboard at any point.

Once it is on, the memory tools show up in Cursor's MCP list like any other server: search_memories for recall, store_memory to save something durable, date_search_memories for time-window questions like what you settled last month. The MCP reference documents the full tool set and the OAuth scopes behind it, and the Cursor page covers the same setup from scratch.

Cursor decides when to check

The tools are model-directed, and Cursor applies that the same way it decides when to search your codebase: sometimes it reaches for memory on its own, sometimes it does not. When a fresh chat misses something you know is saved, "check memory for how we handle auth" is a normal prompt, not a workaround. The same trick covers saving. Tell it to remember the constraint you just explained, and it is there for every future chat.

One vault answers everywhere it is connected. Store a decision in Cursor and Claude, ChatGPT, or Claude Code can recall it; store it in any of them and Cursor gets it back.

Run one test before real decisions go in

Setup takes minutes. Behavior is worth verifying once, with a throwaway fact and no real secrets.

In a connected chat, say: "Store this in MemoryRouter: the orbit demo uses Postgres because we needed transactional migrations." Then watch for the actual store_memory call and its result. If no tool call appears, nothing was saved, regardless of what the reply says.

Open a fresh chat with nothing copied from the first one, and ask: "Search MemoryRouter for the orbit demo's database choice and why." A working path shows the search call and an answer with both Postgres and the migration reason. If it comes back empty, check three things: that you signed into the vault you meant to, which memory_status will confirm with the connection and its scopes, that the server is enabled in Settings, and that the question names memory directly.

Then extend the test once. Connect a second tool to the same vault and ask the same question there. An answer arriving in an app that never saw the original chat is the whole argument for keeping memory outside any single client.

What this does not do

  • It does not import your old chats. The connection changes what future conversations can reach; bringing history in from an archive is a separate workflow.
  • It does not scope itself by repository. One connection is one vault, and the memory tools take no project parameter. If you want a hard boundary between projects, that is a separate vault and a separate connection rather than a label in a prompt.
  • It does not touch Cursor's codebase index. That system indexes code and keeps doing its own job, and the memory layer runs beside it.

Tools with lifecycle hooks, like Claude Code and Codex, capture completed turns without anyone deciding anything. Cursor's connection is model-directed, so asking is the habit that makes recall feel automatic.

If a fresh chat still forgets, the Cursor forgets project context page covers the free fixes first.

Create your MemoryRouter account, add the server entry, and let tomorrow's first chat pick up where today's left off.

All posts