Persistent Memory for Cursor: Close the Chat, Keep the Decisions

John Rood··4 min read

Somewhere in last week's Cursor chat is the reason you rejected the obvious approach. Your code kept the outcome. The chat kept the reasoning, right up until you closed the tab.

So every new Agent chat starts from zero. It asks solid questions, proposes options you already eliminated, and waits while you reconstruct last week out loud. Each reconstruction is small enough to ignore, which is exactly why it compounds.

The connection is one JSON entry

Cursor speaks the Model Context Protocol, including remote servers with OAuth built in. MemoryRouter runs a remote MCP server, so the whole connection is a single entry in mcp.json, scoped globally or per project:

{
  "mcpServers": {
    "memoryrouter": {
      "url": "https://mcp.memoryrouter.ai/mcp"
    }
  }
}

Use ~/.cursor/mcp.json for global scope, or .cursor/mcp.json inside a project. Enable the server under Cursor Settings > MCP and a browser tab handles sign-in. You pick which vault the connection uses while authorizing, and no API key goes into the config, so there is nothing in the repo for anyone to copy. Connections start read-only by default, the write scope gets requested only when something needs saving, and access can be revoked from your dashboard at any point.

Once it is on, the memory tools show up in Cursor's MCP list like any other server: search_memories for recall, store_memory to save something durable, date_search_memories for time-window questions like what you settled last month. The MCP reference documents the full tool set and the OAuth scopes behind it, and the Cursor page covers the same setup from scratch.

Cursor decides when to check

The tools are model-directed, and Cursor applies that the same way it decides when to search your codebase: sometimes it reaches for memory on its own, sometimes it does not. When a fresh chat misses something you know is saved, "check memory for how we handle auth" is a normal prompt, not a workaround. The same trick covers saving. Tell it to remember the constraint you just explained, and it is there for every future chat.

One vault answers everywhere it is connected. Store a decision in Cursor and Claude, ChatGPT, or Claude Code can recall it; store it in any of them and Cursor gets it back.

Run one test before real decisions go in

Setup takes minutes. Behavior is worth verifying once, with a throwaway fact and no real secrets.

In a connected chat, say: "Store this in MemoryRouter: the orbit demo uses Postgres because we needed transactional migrations." Then watch for the actual store_memory call and its result. If no tool call appears, nothing was saved, regardless of what the reply says.

Open a fresh chat with nothing copied from the first one, and ask: "Search MemoryRouter for the orbit demo's database choice and why." A working path shows the search call and an answer with both Postgres and the migration reason. If it comes back empty, check three things: that you signed into the vault you meant to, which memory_status will confirm with the connection and its scopes, that the server is enabled in Settings, and that the question names memory directly.

Then extend the test once. Connect a second tool to the same vault and ask the same question there. An answer arriving in an app that never saw the original chat is the whole argument for keeping memory outside any single client.

What this does not do

  • It does not import your old chats. The connection changes what future conversations can reach; bringing history in from an archive is a separate workflow.
  • It does not scope itself by repository. One connection is one vault, and the memory tools take no project parameter. If you want a hard boundary between projects, that is a separate vault and a separate connection rather than a label in a prompt.
  • It does not touch Cursor's codebase index. That system indexes code and keeps doing its own job, and the memory layer runs beside it.

Tools with lifecycle hooks, like Claude Code and Codex, capture completed turns without anyone deciding anything. Cursor's connection is model-directed, so asking is the habit that makes recall feel automatic.

Create your MemoryRouter account, add the server entry, and let tomorrow's first chat pick up where today's left off.