How to Give Cursor Persistent Memory Across Projects

Cursor is one of the best AI coding tools available. The tab completions are sharp. The codebase indexing is genuinely useful. And as of v1.0 (June 2025), Cursor Memories carries useful facts forward inside a project so you stop re-explaining the same things every conversation.

Memories closed the worst of the session-reset problem. What they didn't close is the boundary between projects, between Cursor and your other tools, and between you and your teammates. The next time you open a different repo, switch to Claude Code, or hand a task off, Cursor's memory of how you work doesn't come with you.

That's not a flaw in Cursor. It's the scope Cursor chose. Memories are deliberately per-project. Extending them across projects and tools is something you bolt on.

What Cursor remembers today

Cursor Memories, shipped in v1.0 (June 2025), store useful facts the model picks up during conversations. Per Cursor's v1.0 changelog, "Memories are stored per project on an individual level, and can be managed from Settings." They're created by a background model that proposes a memory, and you approve it before it's saved. The toggle lives at Cursor Settings → Rules → "Generate Memories." You can review, edit, and delete entries from Settings.

Alongside Memories, Cursor also has Rules. The current format is .cursor/rules/*.md (or .mdc), or an AGENTS.md at the project root. The legacy single-file .cursorrules is deprecated by Cursor's own documentation. Rules are static text you maintain manually, and they load into every conversation in the project they belong to.

For stable conventions and per-project facts, this combination works well. The boundary is what Cursor calls "a project."

Where Cursor's memory stops

Cursor doesn't define what a project is in its Memories docs. In practice, the limit hits in three places:

• Across projects. A debugging insight you saved in one repo doesn't surface when the same symptom shows up in another. The pattern that took you two hours to find on Tuesday isn't there on Friday in a different codebase.
• Across agents. Cursor's Memories live inside Cursor. Open Claude Code, your CLI, or any other coding agent on the same machine and that context is gone again.
• Across teammates. Memories are per-project on an individual level. Your colleague's Cursor doesn't have what you discovered last week unless you wrote it into a rules file by hand.

The reset isn't "every session" anymore. It's every project boundary and every tool boundary.

How MemNexus extends Cursor

MemNexus is an account-scoped memory layer that persists across projects, agents, and tools. The same memory store is reachable from Cursor, from Claude Code, from your CLI sessions, and from anything else that speaks MCP or runs on your machine.

There are two paths into Cursor:

• MCP server. Cursor reads .cursor/mcp.json. MemNexus runs as an MCP server, so Cursor's chat can call memory tools directly inside a conversation.
• mx CLI. The same memory store is available from your shell. mx memories search, mx memories digest, mx memories build-context — useful when you're outside Cursor or scripting against your history.

Both paths talk to the same store. What you save from Cursor is searchable from the CLI, and vice versa.

Want this for your stack? Get on the MemNexus waitlist — cross-project, cross-tool memory in one command.

What you actually use day-to-day

The MemNexus MCP tools map onto a small set of developer scenarios. The names below are the exact tool names Cursor sees:

• build_context — task-start briefing. You sit down, ask Cursor "what was I in the middle of with the billing migration?", and build_context returns active work, key facts, gotchas, and recurring patterns in a single call. Faster than reading three days of chat history.
• recall — cross-conversation digest. "Have we decided how to handle webhook retries?" recall synthesizes a narrative answer from memories across conversations, projects, and agents — not just whatever happens to be in this Cursor window.
• search_memories — direct lookup when you know what you're after. "Find the note about the Stripe idempotency key bug."
• create_memory — save the thing you just figured out. The fix that wasn't obvious. The reason you ruled out an option. Tagged with project context so it surfaces correctly later.

The CLI mirrors these: mx memories build-context, mx memories digest, mx memories search, mx memories create. Same store, different surface.

Setup — one command

mx setup configures Cursor end-to-end. No manual rule file edits.

npm install -g @memnexus-ai/mx-agent-cli
mx setup

What it writes:

• .cursor/rules/memnexus.md — a project-scoped rule block, bounded by <!-- BEGIN MEMNEXUS RULES --> / <!-- END MEMNEXUS RULES --> markers. Tells Cursor when to call which memory tool. Re-running setup updates the block in place.
• .cursor/mcp.json — adds the MemNexus MCP server under mcpServers so Cursor can call the tools above.
• API key — read from your existing config or prompted interactively. Create one at portal.memnexus.ai if you don't have one.

Restart Cursor after setup and the tools are live in chat.

Bonus: CommitContext

During mx setup, you'll be prompted to enable CommitContext. The default is yes. It installs a post-commit git hook that captures the reasoning behind each commit — what you changed, why, and what you ruled out — into your memory store automatically.

The next time you ask Cursor to recall or build_context on a feature, the commit history isn't just diffs and one-line messages. It's the why, searchable. If you skipped it during setup, run mx setup hooks. To browse what was captured: mx commit-context list and mx commit-context show <sha>.

The compound effect

The value isn't obvious on day one. It compounds across projects and tools.

After a month of active development across multiple repos, your memory store reflects the actual trajectory of your work — decisions made under deadline, bugs traced to their root, patterns that emerged from real use. Cursor walks into each session carrying that history. So does Claude Code. So does your CLI. The thing you figured out in repo A is there when the same shape of problem appears in repo B.

You stop re-explaining. You stop re-discovering. The things you've already learned stay learned, regardless of which tool you opened today.

For a detailed comparison, see MemNexus vs Cursor and MemNexus vs Claude Projects.

Get on the waitlist

MemNexus is in invite-only preview. When you're in, you get:

• Account-scoped memory that persists across every project, agent, and tool you use.
• One-command Cursor setup — rules and MCP config written for you, no manual edits.
• CommitContext: every commit's reasoning captured automatically and made searchable.
• The same memory reachable from Cursor chat and your shell.

Request access at memnexus.ai/waitlist.

Using a different AI coding tool?

The same approach works across the AI coding assistant ecosystem:

• Tabnine Memory: How to Make Tabnine Remember Your Project — persistent memory for Tabnine
• Cody Memory: How to Make Sourcegraph Cody Remember Your Project — persistent memory for Sourcegraph Cody
• Continue.dev Memory: How to Make Continue Remember Your Project — persistent memory for Continue.dev
• Kiro Memory: How to Make Kiro Remember Your Project — persistent memory for Kiro
• How to Give Windsurf Persistent Memory — adding persistent memory to Cascade
• GitHub Copilot Memory: How to Make Copilot Remember Your Project — persistent context for Copilot Chat
• JetBrains AI Memory: How to Make JetBrains AI Remember Your Project — persistent memory for JetBrains AI Assistant
• How to give Claude Code persistent memory across projects — persistent memory for Claude Code