iCog
← The iCog Journal
Integrations

Persistent Memory for Cursor (MCP Plugin)

To add persistent memory for Cursor, run CognitiveX as an MCP server and point Cursor at it in .cursor/mcp.json. Cursor doesn't carry context across chats by default, its native Memories feature was removed in v2.1, and Rules are static files you write by hand. CognitiveX gives Cursor one project memory that survives every session, and learns.

Cursor doesn't remember your project

By default, each new Cursor chat starts clean. Conversations are isolated, you can't pull context from another session, and users have reported agent chat history disappearing on IDE restart. The only things that persist are your Rules and your project files. The decisions you talked through yesterday, why you picked that pattern, what the gotcha was, are gone the moment the chat closes.

Cursor did ship a native answer to this. Memories arrived in v1.0 (June 4, 2025): per-project, individual-level facts the agent could reference later, toggled on under Settings → Rules. It was always labeled beta. Then in the v2.1 line (November 2025), it was pulled, staff confirmed Custom Modes were "intentionally removed in Cursor 2.1," and Memories disappeared alongside them. Users were told to export and convert to Rules. So the native memory primitive is, today, gone or in flux.

Rules are not memory

It's tempting to reach for Rules as the replacement. They're not the same thing. Rules (.cursor/rules/*.mdc, with description / globs / alwaysApply frontmatter) are static, manually authored config files you keep in version control. They encode standards you write by hand, they are not automatically learned from your codebase or your sessions.

That's the honest gap. Rules are a great place to declare "use tabs, prefer named exports." They are a terrible place to capture "we tried the optimistic-update approach in March and it caused a double-write, so we moved the mutation server-side." Nobody hand-edits an .mdc file every time they learn something. Memory has to observe and write itself, or it doesn't happen.

Add CognitiveX as a Cursor MCP server

CognitiveX is a hosted memory backbone exposed over the Model Context Protocol. There is nothing to run locally. Cursor is an MCP client, so wiring it in is one config file pointing at the hosted endpoint. The fastest path is the CLI:

npm install -g @cognitivx/cli
cogx auth login
cogx mcp install cursor

That writes the entry below for you. To do it by hand, Cursor reads MCP config from .cursor/mcp.json (project-scoped) or ~/.cursor/mcp.json (global), using the standard mcpServers shape with a hosted URL and a bearer token:

{
 "mcpServers": {
 "icog": {
 "url": "https://api.cognitivx.io/mcp",
 "headers": { "Authorization": "Bearer YOUR_API_KEY" }
 }
 }
}

Create the key at developers.cognitivx.io/keys. Put the file in .cursor/mcp.json to scope memory to one repo, or in ~/.cursor/mcp.json to share one memory backbone across every project you open in Cursor. Restart the agent, and recall / remember become tools Cursor can call.

This mirrors exactly how you'd wire CognitiveX into Claude Code, same protocol, same mcpServers block, same backbone. If you want the protocol-level walkthrough on its own, see running an MCP memory server.

The session-hook pattern: recall in, remember out

A memory layer only earns its keep if it's used at the right moments. The pattern that works in Cursor is two bookends per session:

  1. Recall at the start. Before you start a task, have the agent call recall with the topic ("auth flow," "the billing migration"). It pulls the handful of past memories that actually matter into context, decisions, gotchas, what you already tried.
  2. Remember at the end. When a task wraps, have the agent remember what changed and why. A decision, a bug root cause, a preference. Short and durable, the one sentence future-you would want back.

You can prompt this manually, or bake "recall relevant CognitiveX memory before starting; remember key decisions when done" into a Rule so the agent does it every session. That's the one legitimate use of Rules here: not as the memory, but as the instruction to use the memory.

Mind the 40-tool MCP limit

One Cursor-specific constraint matters for any memory-via-MCP setup: Cursor caps MCP tools at 40 total across all servers. Beyond 40, it only sends the first 40 to the agent, the rest are silently inaccessible (documented in the forum and GitHub issue cursor/cursor#3369).

If you've attached several MCP servers, your memory tools can fall off the edge and just stop working with no error. Keep CognitiveX's exposed tool surface lean, disable tools you don't use on your other servers, so recall and remember always make the cut.

How CognitiveX compares to other Cursor memory tools

No incumbent owns "memory for Cursor." The closest is Basic Memory, an MCP server offering local markdown notes (uvx basic-memory mcp) or a cloud option. Tools like ContextForge, MemNexus, and various forum cursor-memory projects fill the same shape. They all store and retrieve. None of them learn.

Cursor Rules Basic Memory / note stores CognitiveX
Persists across sessions Yes Yes Yes
Written automatically No (hand-authored) No (manually curated) Yes
Episodic → semantic promotion No No Yes
Salience-weighted decay No No Yes
Shared across tools No (per-project) Per-project One backbone, Cursor + Claude Code

The difference is consolidation. A note store is a searchable pile of what you wrote down. CognitiveX consolidates: it promotes episodic events ("we did X today") into semantic facts ("the auth layer uses X"), extracts patterns and skills, and lets low-salience memories decay so recall stays sharp. Those are deterministic algorithms, the LLM only renders the language at the end. CognitiveX has no published recall benchmark, so we won't quote one; the edge we claim is architectural, not a score.

One memory across Cursor and Claude Code

Native Cursor memory, when it existed, was per-project and lived inside Cursor. CognitiveX is one backbone behind a single MCP server, so the same memory is available across projects and across tools, Cursor today, Claude Code in the next terminal, anything that speaks MCP. The decision you captured in Cursor is there when you open Claude Code. That portability is a thing Cursor never offered, native or otherwise. For the deeper take on why a memory layer should live outside any one model, see what an AI memory layer is.

FAQ

Does Cursor remember previous chats or context across sessions? No, not by default. Each new chat starts clean, conversations are isolated, and only Rules and project files persist. Some users have even reported agent chat history vanishing on IDE restart. For memory that survives sessions you need an external layer like CognitiveX.

What happened to Cursor Memories, why was it removed in 2.1? Memories shipped as a beta in v1.0 (June 4, 2025) and was pulled in the v2.1 line (November 2025), alongside Custom Modes, which staff confirmed were intentionally removed. Users were advised to export Memories and convert them to Rules.

Are Cursor Rules the same as memory? No. Rules (.cursor/rules/*.mdc) are static, manually authored config files maintained in version control. They encode standards you write by hand and are not automatically learned from your sessions or codebase.

How do I configure an MCP server in Cursor? Add it to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global) under mcpServers, with command, args, and env. Restart the agent and the server's tools become available.

What is Cursor's 40-tool MCP limit? Cursor sends at most 40 MCP tools total across all servers to the agent; beyond that, the extras are silently inaccessible. Keep your memory server's tool surface lean so recall and remember always make the cut.

Give Cursor a memory that learns

Cursor is a fast editor with a forgetful agent: no cross-session context, a native memory feature that's been removed, and Rules that can't learn. CognitiveX plugs in as an MCP server and gives it one project memory that consolidates instead of just storing, and shares that memory with the rest of your stack.

Ready to stop re-explaining your project every session? Try CognitiveX →