Cursor Memory: What Cursor Remembers and How to Give It Persistent Memory

Cursor is an editor, so it is natural to assume it remembers your project the way a colleague would. It does remember some things, and the way it does so has improved: project rules, generated memories, and AGENTS.md all exist to carry context from one chat to the next. But "Cursor memory" means several different mechanisms, and knowing which one does what saves a lot of confusion when the agent forgets something you were sure you told it.

What Cursor Remembers Today

Rules

Rules are instructions you write that Cursor includes in the prompt. They come in three flavors:

• Project rules live in .cursor/rules/ as .mdc files. Each rule can be always-on, auto-attached when matching files are in context, requested by the agent, or applied manually. The older single .cursorrules file still works but is legacy.
• AGENTS.md is a plain markdown file at the repo root that Cursor reads as project instructions, the same convention other coding agents use.
• User rules are global preferences set in Cursor settings that apply to every project.

Rules are the right place for conventions, commands, and architectural constraints. They are static: Cursor does not update them as it learns.

Memories

Memories are the dynamic counterpart. As you chat, Cursor extracts facts it thinks are worth keeping — a preference you stated, a decision you made — and saves them as project-scoped memories you can review and delete in settings. They are generated automatically and injected into later chats.

Memories are useful, but they are short, flat statements chosen by a heuristic. They do not record why a decision was made, which files it touched, or what happened when the agent tried something that did not work.

Chat and Composer context

Within a single chat, Cursor keeps the conversation, attached files, and tool results in context. Start a new chat and that context is gone unless it was promoted to a rule or a memory.

Where Cursor Memory Falls Short

• No search across history. You cannot ask Cursor what was investigated about a module two weeks ago. If it was not promoted to a memory, it is gone.
• No connections. A memory that says "use the shared API client" is not linked to the PR that introduced it or the exception a later chat agreed to. Contradictions sit side by side.
• Editor-bound. Claude Code, Codex, and an agent running in CI cannot read Cursor's memories, and Cursor cannot read theirs. Teams that use more than one tool keep re-explaining the same context.
• Prompt-bound. Everything above is injected into the prompt, so memory competes with the code you want the agent to look at. That is why rules are supposed to stay short.

These limits are structural: memory stored in files and injected into prompts cannot grow without cost. Persistent memory for agents needs to live outside the prompt and be retrieved selectively.

Giving Cursor Persistent Memory With cognee

Cursor supports the Model Context Protocol natively, which means it can call tools exposed by an external server. cognee runs as an MCP memory server: it stores what you tell it as a knowledge graph plus a vector index and returns the relevant parts when the agent asks.

1. Start the server

echo "LLM_API_KEY=your_api_key_here" > .env
docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main

2. Add it to Cursor

Open Settings, go to Tools & MCP, click Add MCP Server, and add the HTTP endpoint to mcp.json:

{
  "mcpServers": {
    "cognee": {
      "url": "http://localhost:8000/mcp"
    }
  }
}

Save, refresh the MCP tools toggle, and you should see cognee's tools listed.

3. Use it in Agent mode

In the chat panel with Agent mode selected, prompts like "Remember this file in cognee" or "Recall the authentication logic from cognee" call the memory tools. You can also add a project rule that tells the agent to recall relevant memory before starting a task and to remember decisions when it finishes, so the loop runs without you asking.

The full walkthrough, including the local stdio configuration, is in the Cursor integration docs.

What You Get Beyond Rules and Memories

Keep rules for what must load every time. Put the growing record of decisions, investigations, and outcomes in a memory layer that is searchable and shared.

If you also use Claude Code, Claude Code memory covers the same ground for that tool, and both connect to the same cognee server. For the concepts behind the setup, see agent memory and what AI memory is.

Does Cursor have memory between chats?+

Yes, in two forms: Rules you write and Memories Cursor generates from your chats. Both are injected into later prompts. Neither is searchable across history or shared with other tools.

Where are Cursor memories stored?+

Generated Memories are managed in Cursor's settings, scoped per project, where you can review and delete them. Rules live in .cursor/rules/ or AGENTS.md in your repository, and User Rules in your Cursor settings.

Can Cursor share memory with Claude Code?+

Not natively. If both connect to the same MCP memory server, such as cognee, they read and write one shared memory, so a decision made in one tool is available in the other.

Is the cognee MCP server open source?+

Yes. It ships as the cognee/cognee-mcp Docker image and as part of the open-source cognee repository. You can run it locally, in Docker, or on-prem, or use Cognee Cloud for a managed setup.