Cursor Notepad: the workspace memory feature people forget exists

Published 2026-05-11 by Owner

Cursor has a memory feature that doesn’t announce itself. It’s not in the onboarding flow, it’s not mentioned in most tutorials, and it’s easy to mistake for a throwaway scratchpad. It’s called Notepad, and once you understand what it actually does, it fills a gap that neither Cursor Rules nor chat history covers well.

The short version: Notepad stores named blocks of text that live inside your Cursor workspace. You reference them from the chat sidebar using @Notepad, and the content is injected into the model’s context alongside your prompt. The difference from Rules is scope. Rules are code conventions that apply automatically based on file patterns. Notepads are manually invoked — you decide when to pull them into a conversation.

Where it lives and how to use it

Notepad lives in the secondary sidebar panel. If you’ve never opened it, look for the “Notepad” icon in the icon row on the left sidebar (it looks like a document with lines). Clicking it opens a panel where you can create and manage notepads.

To create one:

Click the ”+” button in the Notepad panel
Give it a name — something like conventions.md or sprint-context
Write the content you want to store
Close the panel when done

The notepad saves automatically. There’s no explicit save step.

To reference a notepad from chat:

@Notepad conventions.md — what naming pattern should I use for this new API endpoint?

Cursor resolves @Notepad conventions.md to the full text of that notepad and injects it before your message. The model sees your stored content plus your question as a single prompt. You can reference multiple notepads in one message if needed.

The naming convention matters. Shorter names are easier to type. Descriptive names reduce the chance of grabbing the wrong one. Most of my notepads have .md in the name even though it’s not required — it’s a reminder that they’re meant to be structured like documents.

What notepads store well

Project conventions you’d otherwise repeat in every prompt. If your codebase has a particular way of handling errors, a preferred library for HTTP calls, or a naming scheme for database tables, a notepad called conventions.md holds that context. Instead of pasting a paragraph into every Composer prompt, one @Notepad reference does it.

Prompt templates for recurring tasks. Suppose every sprint review prompt follows the same format: summarize the scope, list acceptance criteria, flag edge cases. Write that template once into a notepad called review-template. When the review session comes, pull the template in, fill in the task-specific details, and send.

Design decisions with rationale. “We’re using Redis for session storage instead of Postgres because we need sub-10ms reads and don’t need transaction guarantees.” That sentence doesn’t belong in a Cursor Rule (it’s not a code-style directive), and it doesn’t belong in chat history (too ephemeral). A decisions.md notepad is the right home. When a question about session handling comes up three weeks later, @Notepad decisions.md puts the rationale back in context immediately.

Longer system prompts. Sometimes a task needs a significant context preamble that would be tedious to type out each time. A notepad called persona-backend or context-data-model can hold a 200-word setup paragraph. Reference it when needed, skip it when not.

What notepads shouldn’t store

Secrets, tokens, or credentials. Notepads are stored in your workspace state — not encrypted, not audited. There’s no credential-safe storage here. Anything sensitive stays in environment variable files that are excluded from context.

Information already in the codebase. If your README.md describes the deployment process, don’t copy it into a notepad. Cursor can read the README directly when you reference it with @README.md. Duplicating it creates two sources of truth and eventual drift between them.

Things that change per session or per task. A notepad with “today’s sprint goals” will be stale by tomorrow. Notepads are useful precisely because their content is stable. For ephemeral context, just type it in the message.

Code snippets you’re actively iterating on. Notepads have no version history. If you’re drafting a complex prompt and refining it, keep it in a plain file under version control, not a notepad. The real notepad sweet spot is content that’s relatively stable and used repeatedly.

Using a notepad for project conventions

The most reliable use I’ve found: a single notepad that mirrors the core of your .cursor/rules/general.mdc, but written for the model in Composer rather than for auto-apply in file editing.

Here’s the structure I use for a conventions.md notepad:

# API layer
- All routes return `{ data, error }` — never throw from a route handler
- Use `zod` for request validation; schema goes in the same file as the route
- Auth middleware runs before every handler via the Express router setup

# Database
- Raw SQL via `pg`; no ORM
- Migration files are in `db/migrations/`; never modify an existing migration
- Table names are singular and snake_case: `user`, `session_token`

# Error handling
- Application errors extend `AppError` (in `src/lib/errors.ts`)
- Don't log errors at the call site; log at the boundary (middleware or top-level handler)

# Testing
- Unit tests alongside source: `foo.test.ts` next to `foo.ts`
- Integration tests in `tests/integration/`
- No mocking of the database in integration tests; use a test schema instead

The difference between this and a Cursor Rule: this gets referenced on demand in Composer, not injected automatically into every Tab completion. For long, structured context, you want control over when it enters the prompt window.

When a Composer prompt needs project context, the reference looks like:

@Notepad conventions.md

The current sprint involves adding a `/orders` endpoint. Here's the
spec: [paste spec]. Write the route handler, zod schema, and db query.

That’s a self-contained prompt. Another engineer with access to the same Cursor workspace can run the same prompt and get the same behavior.

The stale notepad trap

Notepads don’t self-update. If the API layer changes from throwing errors to returning them, the notepad still says the old thing unless someone changes it. A stale notepad is worse than no notepad — the model gets confidently wrong guidance.

Two things that help:

Audit notepads monthly. It takes five minutes to scan them. Ask: does this still reflect how the project works? If not, update or delete. The deletion threshold should be low. An outdated notepad does active harm.

Date major changes in the content. For decisions.md in particular, it’s useful to write “As of April 2026, we use Redis for sessions” rather than a bare present-tense statement. When you review it later, the date tells you whether the context is likely still accurate.

Cursor stores notepads in .cursor/notepads/ at the workspace root. This directory is plain Markdown files — one per notepad, named after the notepad title.

That means they can be committed to git:

.cursor/
└── notepads/
    ├── conventions.md
    ├── decisions.md
    └── sprint-context.md

With this structure:

New team members get the notepads on git clone
When the conventions change, updating .cursor/notepads/conventions.md and committing propagates to everyone on next pull
The notepads serve double duty as lightweight project documentation — readable without Cursor, useful inside it

The .cursor/ directory is often in .gitignore by default. Check that .cursor/notepads/ is included, not excluded, before assuming everyone has access to the shared notepads.

Notepads vs Rules: when to use which

The distinction that took me a while to internalize:

Use Rules for things that should influence every prompt automatically based on file context — code style, naming conventions, patterns to avoid. Rules work in the background.

Use Notepads for things that are too long, too contextual, or too task-specific for a Rule — design rationale, prompt templates, sprint context, anything where you want to decide per-prompt whether it’s relevant.

The two aren’t substitutes. A well-maintained .cursor/rules/ directory and a few focused notepads work better together than either does alone. The rules handle the always-applicable conventions; the notepads handle the context that only matters sometimes.

If you’ve been pasting the same paragraph into Composer prompts repeatedly, that paragraph belongs in a notepad.