Cursor AI Notepads vs Context Files: Stop Feeding It the Wrong Code

You open Cursor, describe what you need, and get back a confident answer that misses the point entirely. The function signature is wrong, the imports are for a library you dropped three sprints ago, or the AI is referencing a pattern from a completely different part of the codebase. The model isn't broken — you're just feeding it the wrong context.

Cursor gives you two distinct tools for controlling what the AI knows about your project: Notepads and context files. Most developers either conflate them or ignore one entirely. Understanding the difference is the fastest way to stop fighting your AI assistant and start getting useful output.

• What Notepads are and when they beat a plain chat message
• How context files (including .cursorrules and .cursorignore) shape every single response
• The practical difference between persistent context and session context
• Common mistakes that flood the context window with noise
• A concrete setup you can copy for a real project

How Cursor Thinks About Context

Before getting into the tools, it helps to understand the problem they solve. Every response Cursor generates is bounded by a context window — a fixed token budget. Whatever fits in that window is what the model can reason about. Whatever doesn't fit is invisible to it.

When you ask a question in the chat panel, Cursor automatically includes some code: the file you have open, any files you've explicitly referenced with @, and whatever the editor infers might be relevant. The trouble is that inference isn't always right, and the automatic inclusions can eat tokens that should go toward things you actually care about.

Notepads and context files are two different answers to the same question: how do I make sure the right things are always in that window?

What Context Files Actually Do

Context files are persistent, project-level instructions. They exist on disk, live alongside your code, and are automatically applied whenever Cursor works with your project. Think of them as standing orders — they don't require you to repeat yourself in every chat turn.

.cursorrules

The .cursorrules file sits at the root of your project and contains plain-text instructions the AI reads before responding to anything. This is where you put conventions that should never need repeating: your preferred language version, the test framework you use, whether you want functional or class-based components, naming conventions, and so on.

# .cursorrules

This is a Python 3.11 project using FastAPI and SQLAlchemy (async).
Always use Pydantic v2 models. Never use `dict()` — use `.model_dump()` instead.
Tests use pytest with pytest-asyncio. Fixtures go in conftest.py.
Do not suggest synchronous database calls.

A well-written .cursorrules file eliminates an entire category of bad suggestions. Without it, you'll spend half your time correcting the AI on things that should be settled once and forgotten.

.cursorignore

The .cursorignore file works like .gitignore but for the AI's file indexing. Cursor indexes your codebase to power its retrieval — it figures out which files are relevant to your current task and pulls them into context automatically. If your repo contains gigabytes of vendored dependencies, generated protobuf files, or legacy code you're not touching, that junk competes for token space with the code that actually matters.

# .cursorignore

node_modules/
dist/
.venv/
migrations/versions/
src/generated/
*.pb2.py

Adding a .cursorignore is low-effort and high-impact. It won't change anything you see in the editor, but it meaningfully improves retrieval quality.

@-referenced Files in Chat

When you type @filename or @folder in the Cursor chat, you're explicitly pinning those files into the context for that conversation turn. This is session-scoped — it doesn't persist beyond the chat. It's useful when you need to ask a question that spans several specific files but don't want those files permanently included.

What Notepads Are

Notepads are a distinct feature: persistent, named scratchpads that live inside Cursor and can be referenced by name in any chat. They're not files on disk (at least not files you manage directly), and they're not chat history. They sit in between — more durable than a chat message, more flexible than a rules file.

You create a Notepad from the Cursor sidebar, give it a name, and write whatever you want in it. Markdown works. Code blocks work. Prose works. Then, whenever you want the AI to read it, you reference it in chat with @NotepadName.

A good mental model: a Notepad is a document you can hand to the AI on demand, without it being baked into every single response. It's context on a leash.

When to Use a Notepad

Notepads shine for information that is specific to a task or phase of work, not the whole project. Here are the patterns that work well in practice.

Architecture decisions for a feature

You're building a new notifications system. You've decided on the schema, the queue strategy, and the retry logic. Write all of that into a Notepad called NotificationsDesign. Every time you ask the AI to write a piece of the feature, include @NotificationsDesign in your prompt. The AI has the full picture without you re-explaining it in each message.

Reproducing a bug

You're debugging a subtle race condition. The reproduction steps are fiddly, and the relevant state is spread across three services. Write the whole scenario into a Notepad — what the expected behavior is, what actually happens, what you've already ruled out. Reference it while you're asking debugging questions. This is far better than pasting the same paragraph into every chat turn.

Onboarding context for a new area of the codebase

You're working in part of the codebase you don't own. Before diving in, read the relevant docs and write a short Notepad summarizing how that subsystem works. Use it as a briefing document for the AI whenever you ask questions about that area.

When to Use a Context File Instead

If the information applies to every interaction with the project, it belongs in a context file. Notepads require an explicit reference — they're opt-in per conversation. Context files are always-on.

Put these in .cursorrules: language version, framework choices, style conventions, architectural constraints, things you never want the AI to suggest, things you always want it to prefer. If you find yourself typing the same instruction in every chat message, that instruction belongs in the rules file.

Put these in .cursorignore: anything that's code but not context — build artifacts, generated files, vendor directories, test fixtures with large payloads, data files checked into the repo.

Common Mistakes That Tank Context Quality

Even with both tools available, there are a few patterns that consistently produce bad results.

Leaving .cursorrules empty

An empty or nonexistent .cursorrules file means the AI makes assumptions about your stack. On a greenfield project where you're making choices as you go, this is fine. On any established project, it's almost always a problem. The AI will default to whatever patterns appear most in its training data, which may not match yours at all.

Dumping your entire README into a Notepad

Notepads have a token cost too. Pasting a 5,000-word README into a Notepad and referencing it constantly is the wrong move. The AI doesn't need your project's marketing copy — it needs the architectural and constraint information. Be selective. A focused 200-word Notepad beats a sprawling 2,000-word one.

Using @-references instead of a Notepad for repeated context

If you're referencing the same file in every chat turn, create a Notepad that summarizes the relevant parts instead. Directly including a large file via @filename repeatedly burns tokens that could go toward more useful context or a longer response.

Ignoring .cursorignore on large repos

On a monorepo or a project with a deep dependency tree, the default file indexing will pull in a lot of noise. Cursor's retrieval will try to surface relevant files, but if there are thousands of files it doesn't understand the relevance of, the signal-to-noise ratio drops. A few lines in .cursorignore solve this quickly.

Writing vague rules

Rules like