Why does Cursor forget my previous sessions?

Cursor forgets previous sessions because every new chat starts with a fresh context window and the agent has no persistent cross-session memory by default. The .cursorrules file and Notepads survive, but the back-and-forth of past chats — decisions, reasoning, half-finished work — does not. The fix is a project memory layer that the agent can read from on every new session.

Cursor stores chat history locally, but storage is not the same as recall. Three design choices drive the forgetting:

1. The agent has no cross-session memory. When you open a new Composer or Chat session, Cursor loads .cursorrules, any open files, and your current prompt. It does not load the message history from yesterday's chat. The agent literally cannot see what you discussed.

2. The context window resets every session. Cursor 2.x runs on models with windows ranging from 200K to 1M tokens depending on the model picked, but that window is per-session. The moment you start a fresh chat, the slate wipes. Long sessions also get summarized as they approach the cap, which means even mid-session, earlier reasoning gets compressed into a one-line note.

3. Old chats are list items, not memory. You can scroll the sidebar and re-open a previous chat to read it. The agent cannot. There is no API for the agent to retrieve or search across past sessions.

The result: your .cursorrules file persists, your code persists, your decisions evaporate.

Every new chat costs you re-orientation time, and the loss compounds across a sprint:

• Reasoning vanishes. "We decided to skip Redis for now because the queue volume doesn't justify it" — that thread is gone. Tomorrow's agent will happily suggest Redis again.
• Half-finished work gets re-attempted. The function the agent started writing in yesterday's chat, with the corner cases you walked it through, has to be re-explained from scratch.
• You repeat yourself, constantly. The same architectural caveats, the same naming conventions, the same "no, we use Drizzle, not Prisma" — pasted in turn after turn, chat after chat.

It is not a workflow problem. It is a memory architecture problem.

Cursor ships three features that partly help. None of them give you real cross-session memory.

`.cursorrules` and the `.cursor/rules/` directory let you write Markdown rules that load into every chat. These are perfect for stable conventions ("use Tailwind, never inline styles") and useless for dynamic context ("we decided yesterday to refactor auth.ts into three files"). Rules are static. Sessions are not.

Notepads are persistent text blocks you can @ into a chat. They survive across sessions, but you have to manually write and update them. Notepads are a great place to drop a spec; they are not a record of how the agent reasoned through it.

Cursor Memories (rolled out in Cursor 2.x) is a feature where the agent saves short notes about you across chats. It is account-level, capped, and summarized — closer to ChatGPT's account-wide memory than to a project memory store. It will remember "user prefers TypeScript". It will not remember the API contract you hammered out in last Tuesday's session.

You can read the official Cursor MCP documentation for how the editor's extensibility works.

For static rules, the natives are fine. For session-spanning project memory, they fall short.

The deeper issue is that session memory cannot live inside Cursor alone. Most devs we talk to use Cursor for fast iteration, Claude Code for long agentic runs, and ChatGPT for design discussions. Each tool keeps its own siloed history. None of them share.

So when "yesterday's session" was actually split across Cursor and Claude Code, no native feature in either tool can stitch it back together. The project is the unit of work; memory needs to follow the project, not the editor.

MemoryLake is a cross-model memory layer that connects to Cursor via MCP. Instead of relying on the editor to remember yesterday, you give the project its own memory store, and Cursor reads from it at the start of every new chat.

• Per-project session memory. Conversations, decisions, and reasoning from every past Cursor chat are stored against the project. New chat opens — the agent already knows what you decided last week.
• 10,000× more context than raw prompting. MemoryLake's retrieval engine reads from billions of tokens of project memory and surfaces only what is relevant per turn. You stop hitting the context cap, you stop re-pasting yesterday.
• Cross-tool continuity. The same project memory works in Claude Code, Windsurf, ChatGPT, Claude Desktop, and any tool that speaks MCP or REST. Hand the project off to a different editor and the context follows you.

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 context. Sign in to MemoryLake, open Project Management, click Create Project, and name it after your repo (e.g., "acme-app — Cursor sessions"). Upload existing specs, ADRs, and past chat transcripts through the Document Drive (PDF, Markdown, Word, Excel, images all supported), or paste standing context into the Memories tab.
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 — it is shown only once.
3. Add the server to Cursor's MCP config. Open or create .cursor/mcp.json in your project root (or ~/.cursor/mcp.json for global access). Add a memorylake entry under mcpServers with the endpoint URL and your Bearer token in the env block. Restart Cursor. The agent now has a memorylake tool it can call at the start of every new session to load project memory.