Persistent Memory for Cursor: Project Context That Survives Sessions
Cursor rules give the editor's agent stable, always-applied conventions. They are static text, though, scoped to one checkout, and not shared with a teammate's Cursor session or a different client working the same repo. A hosted MCP context layer adds what rules cannot: decisions, active work, and impact that change day to day.
What Cursor rules already do well
Cursor project rules live in .cursor/rules. An always-applied rule is a good place for the things every agent chat should know before it starts: coding conventions, architecture constraints, and where the documentation lives. That is the same problem CLAUDE.md and AGENTS.md solve for other clients — a static file that stops the agent from having to be re-taught the same conventions every session.
Rules are deliberately narrow, though. They are written by a person, they do not change unless a person changes them, and they say nothing about what is happening in the project right now.
Where rules and native memory stop
Cursor rules in .cursor/rules are text a person maintains. They describe conventions well but do not capture what changed this week or what is currently in flight.
Rules and Cursor's own memory live inside the editor and the local checkout. They do not travel with the project to a different machine or a teammate's setup automatically.
If the same repository is also worked on from Claude Code or Codex, Cursor's rules and local state do not carry over to those sessions.
Rules can tell Cursor's agent how to write code, but not which files a change is likely to touch or what a similar change affected before.
Rules, session memory, and a hosted context layer
| Layer | Scope | Updates | Shared across agents | Good for |
|---|---|---|---|---|
| Cursor rules (.cursor/rules) | Editor, per checkout | Manual edits only | No — each checkout needs its own copy | Stable conventions Cursor's agent should always follow |
| Cursor chat/composer session | Single chat or composer session | N/A — lost when the session ends | No | The current task, inside the current conversation |
| Hosted MCP context layer | Project, reachable by any connected MCP client | Reviewed captures, not automatic scraping | Yes — Cursor, Claude Code, Codex, and other MCP clients query the same state | Decisions, active work, code impact, verification evidence |
Before and after: starting a task in Cursor
"Implement OAuth." Cursor's agent follows the project rules, then starts searching, guessing conventions the rules did not cover, and rediscovering decisions someone already made in a previous session.
Cursor opens a Start Work Brief through hosted MCP: prior decisions, active work, architecture, likely code impact, and what still needs verification, before the first edit.
How Snipara approaches this
Snipara is a context and memory layer for AI coding agents. It gives each repository a Project Brain powered by Project Intelligence, connecting decisions, active work, code impact, verification evidence and handoffs across Claude Code, Cursor, Codex, Gemini CLI and other MCP clients.
For Cursor specifically, Snipara has two integration layers that stay deliberately separate: a native OpenVSX-published extension for editor UI (sidebar views, command palette, status bar), and hosted MCP for AI chat and composer access to Snipara tools. Running npx create-snipara --client cursor --starter bootstraps a generated Cursor rule, the hosted MCP config, and a doctor check together. The current public Cursor setup is MCP, rules, and tooling — it is not a verified native hook bundle the way Claude Code's lifecycle hooks are.
Limitations
- Cursor's Snipara integration is MCP, rules, and the editor extension — not a verified native lifecycle-hook bundle in the current public setup.
- Cursor still does all the reasoning and editing — Snipara only supplies context.
- Project Intelligence briefs are reviewable evidence views, not canonical project truth or autonomous approval.
- It does not remove the need to run tests or review diffs before merging.
- Snipara is not an LLM provider — you bring your own Cursor client and model.
FAQ
Does Cursor have native hooks for Snipara?
No — not in the current public setup. Cursor's Snipara integration is MCP, rules, and tooling (the editor extension plus Hosted MCP for agent chat), not a verified native lifecycle-hook bundle. Treat any claim otherwise as inaccurate until Cursor's docs say so.
Are Cursor rules enough for project memory?
Rules are good for stable conventions a person wrote down deliberately. They do not update themselves, and they do not represent what changed recently or what a teammate's session already decided — that needs a layer outside the rules file.
How does Cursor connect to Snipara?
Two separate layers: a native OpenVSX-published extension for editor UI (sidebar views, commands, keyboard shortcuts), and Hosted MCP for AI chat and composer access to Snipara tools. Snipara recommends running npx create-snipara to bootstrap both together.
Can Cursor share context with Claude Code or Codex on the same repo?
Yes, through the shared hosted MCP context layer. Cursor, Claude Code, and Codex can each connect to the same project endpoint and query the same reviewed decisions, active work, and code impact, even though their local rules or instruction files are separate.
Does the Cursor extension replace the MCP integration?
No. The extension is a direct editor integration (sidebar, commands, status bar) with its own settings. AI chat and composer access to Snipara tools goes through MCP separately. Snipara's docs recommend using both together.