Cursor's Memories vanished. What to use instead.

Not a complaint about Cursor. A structural point that decides where you should keep things.

Anything that lives inside one editor can be changed or removed by that editor, on their schedule and for their reasons. That is true of every tool in this category, and it will be true of the next one. Features get consolidated, renamed, folded into something else. Your project outlives all of it.

The same shape shows up next door: Anthropic's documentation says of its own automatic memory that it "is machine-local" and that its files "are not shared across machines or cloud environments". Useful, and tied to one place.

So the question is not which editor's memory is best. It is how much of your project's knowledge you are willing to keep somewhere you do not control.

1. Cursor Rules

The native answer, and the right starting point. Markdown files under .cursor/rules, free, in your repository, shared with your team through git. The documentation lists four ways a rule can apply: always, when the model judges it relevant, to specific files, or only when you ask for it by name. Most people use one of the four and never find out about the other three, which is worth ten minutes of your time.

What a rule is, though, is guidance placed in front of the model. It holds instructions well. It does not record what happened, and nothing checks whether it was followed. Start here anyway.

2. A memory-bank folder you maintain

A convention rather than a product: a folder of markdown files the agent reads at the start and updates as it goes. Popular because it works, and because you can read exactly what it knows.

The cost is that you are the process. The agent updates it when it remembers to, it grows without pruning, and nobody notices when it stops being accurate. Genuinely good for a few weeks, and quietly stale after a few months.

3. A memory MCP server

A dedicated store the agent writes facts to and searches later, connected over MCP so it works from any client. Purpose-built for recall, and it survives switching editors, which is the main thing Rules cannot do.

What it stores is facts. It has no notion of the work itself: what is finished, what is next, what failed. If your problem is remembering preferences, this is a good answer. If your problem is that yesterday is a blur, it is only half of one.

4. A project server, such as Mission HQ

The whole project state on a server the editor connects to: the tasks and what they require, the decisions and their reasoning, the session record, and the rules that arrive with the work they govern. Also over MCP, so Cursor connects to it the same way it connects to anything else.

The cost is a subscription after the trial and one config file. What you get for it is that none of it lives inside an editor, so the next version of anything cannot take it away.

Three steps. The whole thing is one config file, and it applies to every project on your machine.

1. Create an account and copy your API key from settings.

2. Open ~/.cursor/mcp.json, creating it if it does not exist, and add the entry below. If the file already has an mcpServers block, merge this into it rather than replacing it.

{
  "mcpServers": {
    "missionhq": {
      "type": "http",
      "url": "https://mcp.missionhq.dev/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

3. Restart Cursor and ask your agent to call mhq_get_handoff. If it comes back with your project state, the connection is live. If the tool is not found, the file is in the wrong place or the key has a typo, and those are the only two things that go wrong here.

The same server works from Claude Code, Cline and other MCP clients, with their own config file in place of this one. The project does not change when the editor does.

Worth saying plainly, because the four options are not exclusive and the best setup uses more than one.

Your Rules files keep doing what they do well: conventions that belong in the repository, versioned with the code, reviewed like code. Nothing here replaces them and you should not delete them.

What moves to the server is the part a file was never shaped to hold: what is finished, what was decided and why, what failed, and what the next session should do first. Your source code stays on your machine either way. What is stored is the project's record, not its contents.