← Back to Blog
Tutorials

How to Give Cursor Persistent Memory Across Projects

Nexus Team • August 14, 2026 • 7 min read

Cursor can read the repository in front of it. It cannot infer the history that never made it into the repository.

It sees the current authentication code, but not necessarily the failed implementation that led to it. It sees a service boundary, but not the discussion where the team decided that boundary was temporary. It sees the issue you are fixing now, but not the related incident you worked through in another repo—or another AI tool.

Persistent memory fills that gap. It stores useful context outside any one Cursor chat or project and retrieves it when the same decision, system, or problem becomes relevant again.

This guide connects Cursor to Nexus-Catalyst through the Model Context Protocol (MCP). The connection uses OAuth, requires no API key in your repository, and can be configured globally or for one project.

What Cursor already knows—and what memory adds

Cursor’s strongest source of truth is your codebase. Rules and project documentation can give it stable instructions. The current conversation carries the immediate task.

Persistent memory adds historical and cross-project context:

  • Decisions made in earlier Cursor sessions
  • Fixes discovered in a different repository
  • Team conventions that span multiple projects
  • Approaches that were tried and rejected
  • Context established in Claude, ChatGPT, or another connected client
  • Personal preferences that should follow you between codebases

The memory does not replace repository documentation. It retrieves the parts of your working history that are unlikely to be encoded completely in the current files.

For a deeper explanation of the underlying loop, see How MCP-Based Persistent Memory Works.

Before you begin

You need:

  • A current version of Cursor with MCP support
  • A Nexus-Catalyst account
  • A browser to complete OAuth authentication

The Nexus-Catalyst remote MCP URL is:

https://mcp.nexus-catalyst.com

Step 1: Choose global or project-level memory access

Cursor allows MCP configuration at different scopes.

Choose global access when you want Nexus-Catalyst available across your Cursor projects. This is the normal choice for personal cross-project memory and shared conventions.

Choose project-only access when the MCP connection should be configured with a particular repository. This can be useful when a team intentionally manages its project configuration together.

The distinction controls where Cursor loads the server configuration. It does not create a separate Nexus-Catalyst account or automatically change ownership of stored memories.

Step 2: Add the MCP server

You can add the server from Cursor’s interface:

  1. Open Cursor → Settings → MCP.
  2. Choose Add new MCP server.
  3. Select HTTP as the transport.
  4. Enter https://mcp.nexus-catalyst.com as the URL.

You can also configure it with JSON. Create or edit .cursor/mcp.json in the appropriate global or project scope:

{
  "mcpServers": {
    "nexus-catalyst": {
      "url": "https://mcp.nexus-catalyst.com"
    }
  }
}

Do not add an API key to this file. Nexus-Catalyst uses OAuth for the Cursor connection.

Step 3: Authenticate

After the server appears in Settings → MCP, Cursor displays a login prompt. Select it to open the Nexus-Catalyst sign-in page in your browser.

Sign in and approve access. If you already use Nexus-Catalyst with another AI client, use the same account. That is how the memory created in one tool becomes available in another.

When authentication is complete, return to Cursor. The nexus-catalyst entry should show a healthy or green connection status.

Step 4: Verify the available tools

The server should expose tools including:

  • recall_context for retrieving context at the beginning of work
  • search_memories for a targeted search during a session
  • get_memory_detail for loading a complete stored record
  • store_context for preserving a decision or outcome
  • get_persona_definition for loading a specialized persona when suggested

The live list and tool parameters are maintained in the MCP tools reference.

Step 5: Store a test decision

Open Cursor’s AI chat in a project and ask:

Store a memory that this repository uses TypeScript strict mode and that database migrations require a rollback section in the pull request.

Cursor should invoke the appropriate MCP tool and confirm that the memory was stored.

Use a real convention if possible. A realistic test makes it easier to recognize whether the correct memory was returned later.

Avoid saving passwords, tokens, or private keys. Persistent AI memory is designed for context, decisions, and working knowledge—not secrets.

Step 6: Recall it from a different project

Open another repository in Cursor and start a new chat. Ask:

What engineering conventions have I established? Use recall_context before answering.

If the MCP server is configured globally and the same Nexus-Catalyst account is active, Cursor can retrieve the earlier memory even though you changed repositories.

That does not mean every memory should apply to every project. Good retrieval considers the current query and available project context. The point of global access is that the history can be found—not that every stored fact is inserted into every prompt.

Three useful cross-project workflows

1. Reusing an architectural decision

Suppose one service has already solved token rotation. In a new repository, ask:

Search memory for our prior token-rotation implementation, including the decision and any failure we encountered.

Cursor can use that history as a starting point while still checking the current repository before making changes.

2. Carrying team conventions between repositories

Store conventions that genuinely span the team’s work:

Remember that externally visible API changes require an ADR and a changelog entry across our services.

When a future task touches an API in another repo, that context can be recalled without copying the same instruction into every chat.

3. Continuing work started in another AI tool

You might design an approach in ChatGPT or review tradeoffs in Claude, then implement the result in Cursor. If both clients read and write the same memory layer, Cursor can retrieve the decision instead of requiring a pasted transcript.

That is the practical value of shared context across AI coding tools: you can choose the best tool for each phase without making yourself the integration layer.

What belongs in memory versus the repository?

Use the repository for information that is authoritative, reviewable, and should travel with the code:

  • Architecture decision records
  • Build and test commands
  • Public interfaces
  • Runbooks
  • Contributor instructions

Use memory for useful context accumulated through the work:

  • Why the ADR was created
  • What failed before the documented solution
  • A related decision from another repository
  • Handoff context that is still evolving
  • Preferences and patterns that span tools

When a recalled fact conflicts with the current code or documentation, the current source of truth should win. Memory should reduce rediscovery, not override evidence.

Improving recall quality

Specific questions retrieve better context than broad ones.

Weak:

What do you remember?

Better:

What did we decide about rate limiting for public API routes, and which approach failed?

The second query contains entities, intent, and the kind of result you need. That gives semantic and structured retrieval more useful signals.

It also helps to store concise outcomes. At the end of meaningful work, ask Cursor to preserve:

  • The decision
  • The reason
  • The affected project or service
  • The result
  • Any failed approach worth avoiding

That creates a reusable project history instead of an archive of disconnected chat messages.

Troubleshooting

The server is not connected

Confirm that the URL is exactly:

https://mcp.nexus-catalyst.com

Then reopen Settings → MCP and trigger the login flow again.

Tool calls return 401

Your OAuth session may have expired. Re-authenticate from the server entry in Cursor’s MCP settings.

The connection works but recall is empty

Verify that memories exist in your Nexus-Catalyst dashboard. Then try a more specific query and explicitly request recall_context.

The server works in one project but not another

Check whether .cursor/mcp.json was added at the project scope. If you want the server available everywhere, configure it at the global scope instead.

For the full current instructions, see the Nexus-Catalyst Cursor setup guide.

One history across your coding work

A repository gives Cursor the present state of the code. Persistent memory gives it a path back to the decisions and discoveries that produced that state.

When the same memory layer is available across projects and AI clients, your context stops being attached to a particular chat window. It follows the work instead.

Test it with one real decision

Connect Nexus-Catalyst globally in Cursor, store one meaningful project decision, and recall it from a fresh repository or another AI client. Start your 14-day Nexus-Catalyst trial to get started.

← More Articles