How to Give Cursor Long-Term Memory Across Sessions

Every Cursor session starts the same way: a blank slate. You explain your stack, your conventions,...

Every Cursor session starts the same way: a blank slate. You explain your stack, your conventions, the bug you chased last Tuesday, and the decision you already made twice. Cursor is brilliant inside a session and amnesiac between them.

Here is the full landscape of fixes, from built-in features to plugins to MCP servers, and what actually stuck for me.

Why Cursor forgets

Cursor's context is session-scoped. Rules files persist, but conversation history, decisions, and debugging context do not carry over. The Composer/Agent sees your codebase, not your history with it. That is the gap every solution below tries to fill.

Option 1: Rules files

Cursor has two levels of persistent instructions:

• Project rules (.cursor/rules/ or .muserules): checked into the repo, shared with the team. Good for coding standards, architecture conventions, "always use X".
• Global rules (Cursor Settings > Rules): apply to every project. Good for personal preferences.

Rules are the right home for instructions, but they are static. They do not record what happened, what you decided, or what failed. And they only live in Cursor.

Option 2: Memory plugins

The Cursor ecosystem has several plugins that add persistent memory:

• Engram: a marketplace plugin that stores conversation transcripts and makes them semantically searchable. Installs from the Cursor Marketplace, uses an API key, exposes MCP tools like search and append_messages, and auto-recalls at session start.
• OpenViking: installs lifecycle hooks that inject relevant context at session start and before each request, then captures conversation turns after each response. Also ships an MCP server.
• Hindsight: a CLI integration wiring Cursor hooks (sessionStart, beforeSubmitPrompt, stop, sessionEnd) to recall-and-retain primitives, with local or self-hosted storage.

These work, but each is Cursor-only. Your memory lives in Cursor's world.

Option 3: File-based memory banks

Tools like skill-memory-bank and Nova keep structured markdown (progress.md, status.md, decision logs) that the agent reads and updates via commands like /mb start and /mb done. Transparent and version-controllable, but you maintain the lifecycle by hand, and again: one tool, one machine.

Option 4: MCP memory servers

MCP (Model Context Protocol) is the open standard for connecting AI tools to external systems, and memory is its killer use case. Generic MCP memory servers give any MCP-compatible client a remember/recall toolset. The pattern is always the same: store liberally during the session, retrieve semantically at the start of the next one.

What I actually use: one memory across every tool

The Cursor-only solutions all hit the same wall for me: I do not live in Cursor alone. I use Claude Code, Cursor, and chat tools across my laptop and phone. Maintaining separate memories per tool is just the re-explaining problem with extra steps.

So I connected Vilix AI over MCP in each tool. It is a memory layer that sits outside any single app:

• Automatic capture: conversation turns are saved without ceremony, no /remember commands, no session-end checklists.
• Retrieval before reply: relevant past context (decisions, preferences, project facts) is pulled in automatically when a new session starts.
• Shared everywhere: the same memory is available in Cursor, Claude Code, and my other connected tools, on my laptop and my phone, because it is stored server-side in my account.
• Setup is ~10 minutes per tool: add the MCP server config, done. There is a free tier.

Cursor's mcp.json setup is the standard snippet every MCP server uses; once it is in, every Cursor session just knows things. No more "as I told you last time" preambles.

Honest limits

No memory system is magic. Retrieval is semantic, so genuinely novel problems still need explaining. Keep rules files for hard project instructions (they are deterministic; memory is probabilistic). And curate occasionally: a memory layer that never forgets anything eventually retrieves noise. The win is not perfect recall, it is never starting from zero.

The short version

If you only ever use Cursor, a plugin like Engram or the rules-plus-hooks setup is fine. If your work spans tools, stop building one memory per app and use one memory for all of them.