How to give Cursor persistent memory

What persistent memory changes for Cursor

Cursor keeps context inside the current chat. Start a new chat, switch branches, or reopen the editor tomorrow and that context is gone. You end up re-explaining the same decisions and re-correcting the same mistakes.

Persistent memory moves the durable facts out of the chat window and into a store the agent can query on demand: repo conventions, prior decisions, local setup quirks, commands that worked, and preferences you do not want to repeat. Cursor supports MCP, so it can reach that store through a standard set of tools rather than a custom plugin.

Start the Remnic server

Remnic runs as a local server that holds your memory store and speaks MCP over HTTP. Generate an auth token and start it on a local port:

export REMNIC_AUTH_TOKEN="$(openssl rand -base64 32)"
npx remnic-server --host 127.0.0.1 --port 4318 \
  --auth-token "$REMNIC_AUTH_TOKEN"

Binding to 127.0.0.1 keeps the endpoint on your machine. The token is the credential Cursor will send on every request, so keep it out of anything you commit.

Point Cursor at the endpoint

Add Remnic to Cursor’s MCP config at ~/.cursor/mcp.json:

{
  "mcpServers": {
    "remnic": {
      "url": "http://localhost:4318/mcp",
      "headers": {
        "Authorization": "Bearer ${REMNIC_AUTH_TOKEN}"
      }
    }
  }
}

Restart Cursor so it reloads the config and connects. Once connected, the Remnic tools appear in Cursor’s tool list. There are over one hundred of them, but a few carry most of the day-to-day weight: remnic.recall to pull relevant memories for what you are doing, remnic.memory_store to save a durable fact, and remnic.entity_get to look up something the store already tracks. The lossless conversation tools let Cursor search archived history when it needs the full record rather than a summary.

How recall works in Cursor

Cursor is an MCP-only client, which means recall is on demand. The model has to call the recall tool for memory to enter the context. That is different from a hook-based host, where recall can be wired to run before the model sees the prompt. In practice you get the most out of Cursor by asking it to check memory at the start of a task, or by keeping a short project instruction that tells it to recall before making changes.

Storing works the other way. When you make a decision worth keeping, tell Cursor to store it. Remnic can also extract durable facts from the conversation so you are not the only source of new memories.

What carries across sessions

Once memory is in the store, it survives the things that reset a chat. A new Cursor chat, an editor restart, and a branch switch all start empty, but the store does not. The facts you saved, the decisions you recorded, and the preferences Remnic extracted are all available through recall in the next session.

Remnic keeps that memory scoped to the project you are in. Working inside a git repository, it routes reads and writes to a project-specific namespace, so what you learn in one repo does not surface while you work in another. Genuinely global preferences still reach every project, so a personal convention you set once follows you around without leaking project-specific notes across repos.

Because the store is plain markdown and YAML on your disk, you can open any memory, read exactly what Cursor will see, and delete or correct it. Nothing is sent to a hosted memory API.

The same setup for Cline, Windsurf, Amp, and more

Cursor is not special here. Any MCP-compatible client takes the same HTTP config: point it at http://localhost:4318/mcp and send the bearer token. Cline, Windsurf, and Amp all connect this way, and they read and write the same store, so memory you build up in one is available in the others.

For a client that speaks MCP over stdio instead of HTTP, run the server in stdio mode:

npx remnic-server --stdio --auth-token "$REMNIC_AUTH_TOKEN"

One store, one token, many clients. You are not maintaining a separate memory silo per tool.

Confirm it is working

After Cursor reconnects, the quickest check is a round trip. Ask it to store a small durable fact, something like the package manager this repo uses. Then open a fresh chat and ask it to recall what it knows about the project. If the fact comes back in the new chat, the store is live and memory is surviving the session boundary that used to erase it.

If nothing comes back, check three things in order. First, that the server is still running and reachable on the port in your config. Second, that the token in ~/.cursor/mcp.json matches the one you started the server with. Third, that you restarted Cursor after editing the config, since it reads MCP settings at startup. A mismatched token shows up as an authorization failure rather than an empty recall, which makes it easy to tell the two apart.

Set it up

Install the Remnic CLI from the install guide, then follow the exact per-client config on the Cursor and MCP clients page. Start the server, add the config block above, restart Cursor, and ask it to recall before your next change to confirm the connection is live.