Does Cursor have memory? Rules, memory banks, and what we found when we used it

Cursor memory isn't an automatic feature in Cursor's current documentation. The context that lasts comes from rules (project, user and team), AGENTS.md and CLAUDE.md files, skills, and the shared files inside Cursor Projects, and all of that lives in your repo, your Cursor account or your team dashboard, so Claude Code, Codex and teammates on other tools never see what Cursor learned. We used Cursor as our main editor before Claude Code and still keep an eye on it, so this post has the docs, the workarounds, and what we found. Docs checked 2026-10-21.

Does Cursor have memory?

No, not as an automatic feature in the current docs. Cursor 1.0 (June 2025) added a Memories beta that could "remember facts from conversations", stored "per project on an individual level" (changelog), but today's rules docs don't mention it, so don't count on it. What you get instead: @Chats pulls context from a previous conversation by hand (help), conversation search finds past agent chats through a local index (help), and rules, AGENTS.md and skills load every time, which makes them the reliable place for context.

The most common complaint is exactly this: Cursor forgets everything between sessions. The usual reply is right, though: a bigger memory isn't the fix, because whatever loads every time also fills the context window, so keep a short agent file and focused rules.

How do I give Cursor memory?

By writing it down where Cursor loads it, in order of effort:

1. AGENTS.md and project rules. Conventions and decisions in AGENTS.md at the repo root and in .mdc rules in .cursor/rules/.
2. A memory bank. A folder of markdown notes and an Always Apply rule that makes the agent read and update them (below).
3. A memory plugin or MCP memory server. From the Cursor Marketplace, or any MCP server in .cursor/mcp.json or ~/.cursor/mcp.json (MCP docs).
4. A shared workspace, when Claude Code, Codex or teammates need the same context (last section).

Which Cursor rules should you use?

Project rules for the codebase, user rules for your habits, team rules for policy.

• Project rules are .mdc files in .cursor/rules/, version controlled, each one Always Apply, Apply Intelligently, Apply to Specific Files, or Apply Manually. A plain .md file in that folder is ignored. Keep each under 500 lines (docs).
• User rules are set in Customize > Rules and sync with your Cursor account (help).
• Team rules are managed in the dashboard on Team and Enterprise; admins can enforce them. Precedence is Team, then Project, then User.
• AGENTS.md in the root is read automatically, nested ones in subfolders too, and Cursor reads CLAUDE.md the same way and always applies it (help). That's the hook for a repo that also uses Claude Code: our CLAUDE.md files are the real rules and the AGENTS.md next to each is a symlink, so Cursor would read the same thing Claude Code does.

What is a Cursor memory bank?

A community pattern, not a Cursor feature: a folder of markdown files plus an Always Apply rule that tells the agent to read them first and update them last. It works because rules and files are what Cursor loads reliably. A minimal version, saved as .cursor/rules/memory-bank.mdc:

---
description: Project memory bank
alwaysApply: true
---
Before any task, read every file in /memory-bank (brief.md, decisions.md, progress.md).
After finishing a task, update progress.md with what changed and what is next.
Add new decisions to decisions.md with the date. Never delete old entries.

The weak points: the agent has to remember to update the files, the bank lives in one repo, and two people editing progress.md at once means merge conflicts. OpenClaw makes this pattern its default (OpenClaw docs); OpenClaw memory covers how that went for us.

What we found using Cursor

We ran Cursor as our main editor in the early days, and back then it was a smart completion engine inside an IDE. Memory and rules didn't come into play much, because the work was still us reading files and Cursor finishing lines. What ended it wasn't a memory problem. Claude Code got good enough that we stopped needing to look at files at all, and when we do need to, we open IntelliJ or WebStorm, which have a better interface than a VS Code fork ever had. Claude Code memory has what we do there instead.

We haven't written Cursor off. We tried the switch from IDE to ADE, the agentic development environment, and it's good; it's a sharp team that iterates fast. Since the SpaceX deal, the model that team has been training with xAI ships in both Cursor and Grok Build, and we do use Grok Build, often, when a task doesn't need a frontier model: the models are fast, capable workhorses. So Cursor's rules and skills matter to us mostly as a format other tools read, not as a place our context lives.

Do Cursor Projects remember context?

Inside the Project, yes. Projects (beta, September 2026) have a coordinator agent that plans work and hands it to other agents, and each Project keeps shared files that sync across every cloud and local machine its agents use: research, artifacts, what agents learn about the codebase, and how you like work done (changelog). They're not available on Free, Plus or the legacy Hobby plan, or with Privacy Mode (Legacy), and the docs don't say whether teammates can share one.

Does Cursor share context with Claude Code, Codex or teammates?

Only through files. Cursor reads CLAUDE.md and AGENTS.md, and loads skills from .claude/skills/ and .codex/skills/ as well as its own folders (docs), but its chats, Project files and what its agents learned stay in Cursor. Teams can share rules, skills through a team marketplace, and read-only shared transcripts that a teammate can "Fork to Cursor" (help); live context doesn't sync, per a July 2026 forum reply. One forum user's line covers it: "I feel like I keep re-explaining the same things between tools" (forum).

For one repo and one team of coding agents, the fix is files: AGENTS.md, a memory bank, skills in .agents/skills/, all committed and reviewed like code. It breaks when context belongs to more than one repo, when non-coding agents need it, when two agents pick up the same job, or when you want a record of who changed what.

How to share Cursor's context with everything else

Everything of ours that more than one agent needs lives in a Tokenrip workspace, and Cursor can connect to it over MCP like the rest. Add this to ~/.cursor/mcp.json (global, so the key never enters your repo), with a key from tokenrip.com/operator/agents saved as TOKENRIP_KEY in your shell profile:

{
  "mcpServers": {
    "tokenrip": {
      "url": "https://api.tokenrip.com/mcp",
      "headers": { "Authorization": "Bearer ${env:TOKENRIP_KEY}" }
    }
  }
}

Use the key header rather than OAuth: Cursor's MCP docs describe OAuth through dynamic client registration or static client credentials, and Tokenrip's OAuth server uses Client ID Metadata Documents instead. Then ask the agent to "open my Tokenrip workspace". It loads the pinned decisions, files, open tasks and the last handoff note, the same ones Claude Code and our Grok Bots work from, and a task it starts is held under a lease so no other agent takes it. Or let an agent do the setup: paste this into it, and you give an email address and a six-digit code.

Connect me to Tokenrip. Fetch https://tokenrip.com/setup?ref=cursor-memory and follow it.

Related reading

• Claude Code memory
• Codex memory
• Why Cursor and Claude Code can't share context
• Claude Code for teams