---
title: "How Cursor Memory Works: Rules and Memories"
description: "Cursor memory from the official docs: rules vs the memories feature, what persists across chats and machines, plus controls, deletion, limits."
canonical: https://past.dev/blog/cursor-memory
date: 2026-09-02
category: Research
authors: The past.dev team
---
# How Cursor Memory Works: Rules and Memories

Cursor memory is two systems with one job. Rules are context you author: files in `.cursor/rules` and settings-level instructions that Cursor injects at the start of every relevant conversation. Memories are context Cursor learns: facts extracted from your agent chats, saved per project after you approve them. Underneath both, Cursor searches your codebase automatically, so the repository itself supplies most project context without anything being written down. Cursor's rules documentation states the premise plainly: "Large language models don't retain memory between completions" ([Cursor Docs](https://cursor.com/docs/context/rules)). This post documents each layer from Cursor's documentation and changelog, as of September 2026.

## Cursor rules: the authored layer

Project rules live in `.cursor/rules` as `.mdc` files, version-controlled and shareable through the repository, with subfolders allowed for organization ([Cursor Docs](https://cursor.com/docs/context/rules)). Frontmatter decides when each rule loads. There are four modes:

- `alwaysApply: true` includes the rule in every conversation. Globs and description are ignored.
- A `description` with `alwaysApply: false` lets the agent pull the rule in when it judges it relevant.
- `globs` (for example `**/*.tsx` or `src/**`) auto-attach the rule when a matching file is in context.
- A rule with none of those loads only when you @-mention it in chat.

"When applied, rule contents are included at the start of the model context" ([Cursor Docs](https://cursor.com/docs/context/rules)). The same page carries the only documented size limit: keep rules under 500 lines and split large rules into smaller composable ones. A plain `AGENTS.md` at the project root works as an alternative, and nested `AGENTS.md` files apply to their directory and its children, with more specific files taking precedence.

Beyond the project, User Rules apply across all your projects in Agent chat. Set in Cursor Settings, they are "stored on your Cursor account" and sync when you sign in on another machine; rule files placed in `~/.cursor/rules` stay on that machine and do not sync ([Cursor Docs](https://cursor.com/help/customization/rules)). Team and Enterprise plans add Team Rules managed from the Cursor dashboard, with an enforcement option that prevents individual users from disabling a rule. Application order is Team Rules first, then Project Rules, then User Rules ([Cursor Docs](https://cursor.com/docs/context/rules)). Rules steer the Agent; the docs state they do not affect "Cursor Tab or other AI features."

One piece of history matters for older repositories: "The `.cursorrules` file in your project root is legacy and will be deprecated." The documented migration is to recreate its content as an Always Apply rule in `.cursor/rules` and delete the old file ([Cursor Docs](https://cursor.com/help/customization/rules)). Writing good rules is [context engineering](/context-engineering) in the most literal sense: you decide what every future conversation begins with.

## The Cursor memories feature: the learned layer

Memories arrived in Cursor 1.0 in June 2025 as a beta: "With Memories, Cursor can remember facts from conversations and reference them in the future." They are "stored per project on an individual level, and can be managed from Settings," and were enabled from Settings > Rules ([Cursor Changelog](https://cursor.com/changelog/1-0)). Version 1.2 in July 2025 declared "Memories is now GA" and "introduced user approvals for background-generated memories to preserve trust" ([Cursor Changelog](https://cursor.com/changelog/1-2)). A memory proposed in the background therefore waits for your sign-off before it is saved.

The distinction between the two layers is worth stating exactly. A rule is deliberate: you wrote it, you can diff it, and a project rule travels with the repo to every teammate. A memory is extracted from your own chats, scoped to one project and one person, and reviewed at save time rather than at write time. The changelog wording ("on an individual level") means your memories do their work for you alone rather than for the team.

One observable oddity as of September 2026: Cursor's public documentation index at [cursor.com/docs](https://cursor.com/docs) lists no dedicated Memories page, and the rules documentation does not mention the feature. The two changelog entries above remain the official description of how it behaves.

## What Cursor memory carries across sessions

Persistence in Cursor depends on which layer holds the information:

- Project rules and `AGENTS.md` files persist in git, so they reach every future conversation and every teammate.
- User Rules set in Cursor Settings persist on your account and follow you across machines; `~/.cursor/rules` files persist on one machine only ([Cursor Docs](https://cursor.com/help/customization/rules)).
- Approved memories persist per project for you, and Cursor references them in future conversations ([Cursor Changelog](https://cursor.com/changelog/1-0)). This is the only layer that qualifies as learned [cross-session memory](/glossary/cross-session-memory).
- Chat transcripts are history rather than memory. Cursor documents search across "past agent transcripts" through a locally built index ([Cursor Docs](https://cursor.com/help/ai-features/conversation-search)), and nothing in the documentation says the agent re-reads old conversations on its own.

Cloud Agent automations get a fourth, separate mechanism. "Memories let the agent read and write persistent notes across runs for the same automation," stored as a named entry (`MEMORIES.md` by default) that lives outside the agent's working filesystem ([Cursor Docs](https://cursor.com/docs/cloud-agent/automations)). They are enabled by default, viewable and editable from the tool configuration UI, and deletable there or by the agent itself. Cursor attaches a direct warning: automations that handle untrusted input can pick up "misleading or malicious memories" that affect future runs.

The last layer is implicit. Cursor's search documentation describes Instant Grep, "a custom search engine that outperforms `ripgrep` on large codebases" that "runs automatically; no configuration needed," plus an Explore subagent for parallel searches ([Cursor Docs](https://cursor.com/docs/context/codebase-indexing)). On privacy, the page commits to two mechanics: "File paths are encrypted before being sent to Cursor's servers. Code content is never stored in plaintext." Your codebase acts as the reference store, and the agent re-derives project knowledge from it on demand.

## Controls, deletion, and documented limits

Everything above has a documented off switch. Memories are enabled or disabled from Settings and reviewed there, per the 1.0 changelog. Background-generated memories require approval before saving, per 1.2. Rules are deleted by deleting the file; enforced Team Rules are the exception a user cannot turn off. Automation memories can be removed from the tool configuration UI. The documented limits are few: the 500-line guidance for rules, per-project and per-person scope for memories, and per-automation scope for automation notes. Cursor documents no cap on memory count, no expiry date on saved memories, and no way to share memories with a teammate.

## For builders: what this design gives you and what it cannot

If you are building an agent product of your own, Cursor's split is instructive: authored rules, learned per-project memories with human approval, and derived context from source data. Those memories stay inside Cursor, so an agent you ship needs its own memory layer, which is what past.dev provides as an API. POST /api/v1/ingest accepts raw text with its original timestamp (fields content and timestamp), entity resolution links references to the same person across sources, and facts carry event time, validity windows, and supersession links; POST /api/v1/recall (field query) returns ranked, dated evidence with sources and one of four status values: Supported, Conflicted, NoKnownSupport, or UnknownBecauseDegraded. Deployment is managed or self-hosted in your own Postgres; see the [quickstart](/docs/memory-api/quickstart) and the [benchmarks](/benchmarks).