How do I give Cursor persistent memory across chats?

Give Cursor persistent context with project rules or AGENTS.md for stable instructions, and an MCP memory server for selectively saved private context. Rules are loaded into future chats; a memory server stores records Cursor can retrieve through tools. For Cairn.ink Memory, configure hosted MCP in Cursor and verify a save in a fresh conversation.

Which context should I put in rules?

Use rules for expectations you want applied repeatedly: how to find tests, where architectural decisions live and which conventions matter for a part of the codebase. Put the actual build command in maintained project configuration, with a short instruction telling Cursor where to find it.

The current official Rules documentation, accessed 2026-11-12, lists project, user and team rules, plus AGENTS.md. Project rules live in .cursor/rules as .mdc files. User rules apply across your Cursor environment; team rules are managed through the dashboard on the documented team plans.

Choose AGENTS.md if you want a simple Markdown instruction file shared with other coding tools. Choose .mdc rules when you need Cursor-specific control over how instructions apply. Store project rules with the code so collaborators can review and update them alongside implementation changes.

How can I make one project rule persist?

For a simple starting point, create or update the repository's AGENTS.md with a short rule such as this illustrative content:

Read package.json before choosing test commands.
Check the relevant architecture document before changing storage.
Report the actual test result with your changes.

For a Cursor project rule, use .cursor/rules/project-context.mdc. The official docs describe alwaysApply, description and globs metadata. This example uses their always-applied form with illustrative instructions:

---
alwaysApply: true
---

Read package.json before choosing test commands.
Check the relevant architecture document before changing storage.
Report the actual test result with your changes.

Choose one home for those instructions and merge them with existing guidance. In a fresh Agent chat, ask Cursor to identify the applicable rule and explain which project file it will consult for the test command. Compare its answer with the maintained file before starting the edit.

For specialized rules, the documented application choices include always applying, matching specific files, selection by relevance and manual mention. Use a file-matched rule for a particular part of a large repository. A short relevant instruction is easier to maintain than one growing global prompt containing every past decision.

What happened to Cursor's own Memories feature?

Cursor's 1.2 announcement, dated July 3, 2025 and accessed 2026-11-12, announced Memories as generally available and added user approval for background-generated memories. That is official evidence of the feature's historical behavior.

On 2026-11-12, the former Memories documentation route redirects to Rules, and the current Rules page does not establish that the old Memories controls remain available in your installation. Check the settings actually shown in your installed version, use any documented approval and inspection controls it provides, and keep required project guidance in maintained rules.

For current setup, the directly documented paths are rules and MCP connections. Start with those when you need a reproducible configuration that another contributor can inspect. If a native saved preference already meets your need, keep its ownership and maintenance clear alongside your project instructions.

When is an MCP memory server useful?

An external memory store is useful for private preferences or selected context you want to retrieve across chats, projects or other assistants. For example, your explanation preference belongs to you, while the team's release process belongs in its reviewed source. A shared private store lets the preference follow you without adding it to every repository.

Cursor's official MCP guide, accessed 2026-11-12, describes external tools, local and remote transports, configuration locations and OAuth. MCP means Model Context Protocol: it gives Cursor operations supplied by a server. The server determines which records are saved, how they are scoped and which identity can retrieve them.

Choose a server with the inspection and deletion controls you need. Then test one record across fresh chats before moving useful personal context into it. Keep your first test personal rather than project-scoped so the result is easy to separate from project-identity configuration.

How do I connect Cairn.ink Memory to Cursor?

For people also using Claude Code or Codex, the main Cairn.ink Memory setup path for those clients is:

npx @cairn-ink/memory setup

Cloud connects the first paired installation with one browser sign-in and provides automatic capture and prompt recall. Close the clients and finish background work before confirming sharing, then reopen them and review the four entries in Codex /hooks. Local offers free, no-account explicit tools on one computer. These installer paths target Claude Code and Codex; configure Cursor separately using hosted MCP.

For Cursor, the website's connection flow offers Open in Cursor, followed by browser sign-in. The manual fallback uses the same HTTP configuration. Open or create ~/.cursor/mcp.json for a connection available across projects, and merge this server into any existing mcpServers object:

{
  "mcpServers": {
    "cairn": {
      "type": "http",
      "url": "https://cairn.ink/api/mcp"
    }
  }
}

For project-specific configuration, use .cursor/mcp.json. The current official MCP guide uses the Customize page for managing servers. Enable the connection, complete browser OAuth with your intended cairn.ink account and inspect the available tools. Use the same account as the other client when sharing private context.

The configuration follows the website's connection instructions and the released installer documentation. Cursor uses explicit hosted memory tools; this connection does not add the installer's automatic capture to Cursor.

How do I check that a fresh chat remembers?

In Cursor, use a harmless synthetic preference and request a real save:

Use remember_memory to save this in personal scope:
For the fictional Fern demo, I prefer review summaries to start with test results.
Show the Memory ID and Source Receipt returned by the tool.

Read the successful tool response and keep its identifier for your own comparison. Cairn.ink Memory's Source Receipt contains the source excerpt and client metadata explaining the Memory's origin. Private Memory and shared Knowledge Cards have separate review and publication lifecycles.

Open a fresh Cursor chat without pasting the preference or earlier answer:

Use recall_memory to find my review-summary preference for the Fern demo.
Show the returned Memory ID and Source Receipt, or report no matching result.

Compare the returned identifier and source with the save. Once that works, read the same personal Memory from a fresh session of another configured client. For project-private testing, use the supported opaque project identity supplied by the integration.

What should I check if the result is empty or stale?

A connected server indicator is not a persistence test, so inspect the save and retrieval responses. A Source Receipt describes origin rather than current correctness, so compare technical facts with maintained project sources.

For an empty result, check the endpoint, account, enabled tools and scope, then resolve any authentication or tool error. For stale context, find the exact record before changing it; hosted Cairn.ink Memory exposes forget_memory for an exact Memory ID. Keep a harmless retained record as a comparison when checking that the retired one stops appearing.

Use the connection guide to finish Cursor's separate hosted setup.