Why does Cursor forget my project rules?

Cursor forgets your project rules because rules are appended to the prompt as static text and compete with code context for a finite budget. Glob-scoped rules only fire when the file path matches, and alwaysApply rules still lose weight as the prompt fills with retrieved code. The legacy .cursorrules format is also being deprecated in favor of .cursor/rules/*.mdc. The fix is to make rules queryable context rather than prompt-stuffed text.

Cursor's Rules system, especially the newer .cursor/rules/*.mdc format with YAML frontmatter (description, globs, alwaysApply), is a real attempt at scalable per-project guidance. The mechanics still leak.

1. Rules share prompt budget with code. Every rule that fires gets prepended to the prompt. The more files Cursor pulls in as context, the less effective room rules have. Important guidance ends up early in the prompt where models give it less weight than the recent code at the end.

2. Glob scoping is silent. A rule with globs: src/components/**/*.tsx will not fire when you edit a .stories.tsx file in the same folder unless you broaden the glob. The rule is technically present in the repo, just absent from this prompt, and Cursor will not warn you.

3. Long sessions evict context. Once a session loads many files, the model's effective working context drops, and earlier instructions, rules included, lose weight against the recent code. Style and rule drift on bigger refactors is a well-documented pattern in Cursor user feedback.

4. The legacy format is going away. .cursorrules in the project root is still supported but marked for deprecation in favor of .cursor/rules/*.mdc. Projects that have not migrated end up with rules that load inconsistently.

The result: a thoughtful rules setup that works on tiny tasks and slips on the bigger ones.

Every rule miss costs you review time, and the cost compounds across a real codebase:

• Architectural guardrails fall. "No direct DB calls from React components" gets violated three files into a refactor, and you only notice in review.
• Security rules slip. "Never log request bodies" gets broken in a new logger utility because the glob did not match.
• Convention enforcement softens. "Use the shared useQuery wrapper, not raw fetch" gets ignored because the rules file lost weight late in a long prompt.

The fix is not "make every rule alwaysApply." That just pushes more text into every prompt and accelerates the eviction problem. The fix is to make rules retrievable on demand, scoped to the change at hand, instead of statically prepended.

Cursor has shipped real machinery here. None of it fully closes the gap.

*Project Rules (`.cursor/rules/.mdc)** support frontmatter with description, globs, and alwaysApply, so you can scope rules by file path and decide whether each rule fires every time or only on match. This is the modern, recommended format and a clear improvement over the legacy .cursorrules` file.

Memories auto-generate short rules from chat history and scope them to the project. They are useful as a baseline but are summaries of inferred preferences, not authoritative contracts.

Native MCP support lets Cursor pull context from external servers through .cursor/mcp.json or the Settings UI. This is the cleanest escape hatch, because MCP returns context on demand instead of consuming prompt budget upfront.

You can read Cursor's own documentation on Rules in the official Cursor docs.

For light use, Rules and Memories handle it. For dense, rule-heavy codebases, the natives drift.

The deeper issue is that rules in a real codebase are layered: architecture rules, framework rules, security rules, team conventions, and decisions made in code review last week. Stuffing all of them into static .mdc files and hoping the prompt budget holds is brittle. It also locks the rules inside Cursor when many teams now run Cursor, Claude Code, Cline, and Copilot variants in parallel.

That is what a cross-tool memory layer fixes: one rule store, retrieved on demand, scoped to the change, and shared across every AI editor on the team.

MemoryLake is a cross-model memory layer that sits between you and every AI you use. Instead of relying on Rules files alone, you store rules in a MemoryLake Project, and Cursor retrieves the right slice per edit through MCP.

• Retrieved on demand, not prompt-stuffed. Cursor calls the MemoryLake MCP endpoint per turn and gets only the rules relevant to the file under edit, so rules stop competing with code for prompt budget.
• Versioned and auditable. MemoryLake's Git-style version control tracks every rule change, who made it, and why, which matters when a rule breaks behavior and the team needs to roll back.
• Portable to every other AI coding tool. The same rule set works in Claude Code, Cline, Windsurf, and any MCP-aware editor. When a teammate switches tools, the rules follow.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, the top published result as of 2026, with millisecond retrieval and AES-256 end-to-end encryption.

1. Create a project and load your rules. Sign in to MemoryLake, open Project Management, click Create Project, and name it after the repo (for example, "Cursor - payments-service rules"). Import your .cursor/rules/*.mdc files into the Document Drive, and write your highest-value rules as structured entries in the Memories tab so they are retrievable by topic.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Cursor integration", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the secret immediately, since it is shown only once.
3. Connect Cursor. Cursor has had native MCP support since 2025, which makes this the cleanest path. Add a MemoryLake server entry to .cursor/mcp.json at the repo root (or wire it through Cursor Settings > Features > MCP), paste the endpoint URL and Bearer token, and reload Cursor. Your .mdc rules can stay in place as a baseline; MemoryLake supplies the deeper, retrievable rule store on demand.