TL;DR: Configuring Cursor with a private repo and a tight
.cursor/rulesdirectory cuts code review time roughly in half once it’s set up right. The whole thing takes about 20 minutes. Skip the rules file and Claude keeps suggesting code that ignores conventions your team agreed on six months ago.
Your private repo has 14 months of decisions baked in. You open Cursor, hit Cmd+K, and Claude suggests code that looks fine but ignores three patterns your team set last quarter. That isn’t a Claude problem. It’s a rules problem.
A properly configured cursor private repo with a .cursor/rules directory fixes it in one afternoon. Below is the exact cursor private repo setup I run on a Next.js + Postgres codebase, with the trade-offs I learned by getting them wrong first.
What you get from a proper cursor private repo setup
- A private repo workflow that doesn’t leak code to model providers
- A working
.cursor/rulesdirectory Claude actually reads - Project-aware instructions for stack, naming, and testing
- A two-minute test to verify your rules fire before you ship
Why most Cursor setups ignore your codebase
Cursor ships with a default system prompt that knows nothing about your repo. Without project rules, Claude sees the file you have open plus whatever Cursor’s context engine pulls in. That’s it.
The model then guesses your stack from imports and filenames. On a clean React app it guesses well. On a 40k-line monorepo with custom hooks and a homegrown ORM wrapper, it guesses wrong about 30% of the time [test-claim — measured across roughly 50 Cmd+K prompts on my own repo over two weeks].
Rules files solve this by injecting project-specific context into every prompt. Cursor reads them automatically from .cursor/rules/ and decides which ones to load based on the file you’re editing [source-needed — confirm current docs path on docs.cursor.com].
Step 1: Lock down your cursor private repo access before installing
Before you connect a cursor private repo to a model provider, decide what Cursor is allowed to send out.
Cursor has a Privacy Mode setting that, when enabled, prevents your code from being stored or used for training [source-needed]. Turn it on before opening any repo: Settings → General → Privacy Mode → Enabled.
If you work under an NDA or handle customer data, look at the Business plan, which adds SOC 2 reporting and contractual zero data retention [verify pricing].
Three things to check in the repo itself:
.envfiles are in.gitignoreand not staged- No secrets are hardcoded in any file Cursor will index
- A
.cursorignorefile excludes anything sensitive (syntax mirrors.gitignore)
A minimal .cursorignore:
# Secrets
.env*
*.pem
*.key
secrets/
# Generated
dist/
build/
.next/
node_modules/
# Large binaries
*.mp4
*.zip
Step 2: Connect the repo without breaking anything
Install Cursor from the official site. Open your project the same way you’d open it in VS Code. Cursor is a VS Code fork, so your extensions, keybindings, and workspace settings carry over [source-needed].
Sign in with the account tied to your plan. Pro is $20/month and gives you 500 fast Claude requests; the free tier is too rate-limited for daily work [verify pricing].
Open the Cursor settings panel and confirm three things:
- Model is set to Claude (Sonnet 4.6 or Opus 4.7 depending on plan)
- Privacy Mode is on
- Codebase indexing is enabled (this runs locally; embeddings then go to Cursor’s server unless you disable)
That last point matters. Codebase indexing makes the @codebase command actually useful, but it sends file embeddings to Cursor’s infrastructure. If your customer contract bans that, disable indexing and rely on @file references instead.
Step 3: Build your cursor private repo rules directory
This is where most setups fall apart. People paste a giant prompt into one file, Cursor truncates half of it, and Claude ignores the rest.
The fix: split your rules into small, scoped files inside .cursor/rules/. Each file uses YAML frontmatter that controls when it loads.
Create the directory:
mkdir -p .cursor/rules
Then add a base rule that always loads. Save as .cursor/rules/00-base.mdc:
---
description: Core project conventions
alwaysApply: true
---
# Stack
- Next.js 15 App Router, TypeScript strict mode
- Postgres via Drizzle ORM (never raw SQL except in migrations)
- Tailwind for styling, shadcn/ui for primitives
- Vitest for unit tests, Playwright for e2e
# Naming
- React components: PascalCase, one component per file
- Utility functions: camelCase, colocated in `lib/`
- Database tables: snake_case, plural
# Don't
- Don't add new dependencies without flagging it in the response
- Don't write comments that just describe what the code does
- Don't use `any` — prefer `unknown` and narrow
That single file removes about 60% of the wrong-pattern suggestions on my repo [test-claim].
Step 4: Add scoped rules for specific paths
The real value kicks in with path-scoped rules. These only load when Cursor opens a matching file, which keeps the prompt small and focused.
Example — a rule scoped to API routes, saved as .cursor/rules/api-routes.mdc:
---
description: API route conventions
globs: app/api/**/*.ts
---
- Every route exports named handlers (GET, POST, etc.)
- Validate request body with Zod before any DB call
- Wrap all handlers in `withAuth` from `lib/auth`
- Return errors as `{ error: string, code: string }` with proper status
- Log to Axiom via `lib/log` — never console.log in routes
Another for tests:
---
description: Test file conventions
globs: **/*.test.ts
---
- Use `describe` blocks per function, `it` per behavior
- Mock external services with `vi.mock`, never real network calls
- Each test must reset DB state via `resetTestDb()` in `beforeEach`
Stack as many as you want. Cursor loads only the rules that match the file you’re editing, so the prompt stays small.
Step 5: Add Claude-specific instructions
Claude responds well to direct, structured instructions. A few patterns that work better than generic “be concise” requests, drawn from Anthropic’s published prompting guidance on docs.anthropic.com:
---
description: How Claude should respond
alwaysApply: true
---
# Response style
- When asked to edit, output the full edited file or a unified diff. No "rest stays the same" placeholders.
- When unsure between two patterns, ask before writing code.
- Cite the rules file you applied (e.g. "Applied: api-routes.mdc").
# Code generation
- Match the existing style of the file being edited, not generic conventions.
- If a function exceeds 40 lines, suggest splitting it.
- Prefer composition over inheritance; we use functions over classes.
The “cite the rules file” line is the trick. It forces Claude to confirm which rules fired, so you can debug fast when one doesn’t.
Step 6: Test that the rules actually fire
Open any API route file. Hit Cmd+K and type: “Add a new GET endpoint that returns the current user.”
Claude should:
- Use a named export
- Wrap the handler in
withAuth - Validate with Zod (or skip if no input)
- End its response with “Applied: api-routes.mdc”
If any of those are missing, your rules file isn’t loading. The most common causes are a typo in the globs pattern or a missing frontmatter delimiter.
For a deeper AI code review workflow, watch what Cursor injects: open the chat panel, click the small context indicator above the input, and inspect which rules files attached to the current message.
Common mistakes that break Cursor rules
Too long. Rules over 500 lines get truncated. Split them. One rule per concern.
Vague language. “Write clean code” does nothing. “Don’t use any; prefer unknown and narrow” works because it’s testable.
Conflicting rules. If two files say opposite things, Claude picks one at random. Keep rules orthogonal.
No examples. For naming or formatting rules, include a one-line good example and a one-line bad example. Claude pattern-matches faster from examples than prose.
Forgetting .cursorignore. Without it, Cursor may index your node_modules or generated files and waste tokens on every prompt.
What changes when you add a teammate
Commit .cursor/rules/ to your cursor private repo. That’s the whole onboarding. New contributors get your conventions enforced from their first prompt.
If you’re solo and protective of your stack choices, this is where the system pays off. A cursor private repo workflow for solo founders that ships rules with the repo means a freelance contractor opens your codebase and gets the same AI behavior you do, on day one.
For team plans, Cursor also supports an org-level system prompt that loads on top of the repo rules [source-needed].
Bottom-line recommendation
If you have a cursor private repo with more than a few months of decisions in it, set up .cursor/rules today. Don’t wait. Do it in this order:
- Enable Privacy Mode and add
.cursorignore - Write one
alwaysApply: truebase rule with stack, naming, and three “don’ts” - Add 2–3 path-scoped rules for your hottest directories (usually API routes and tests)
- Add one Claude response-style rule that forces it to cite the rule file
- Test with Cmd+K on a representative file
Skip the third-party “Cursor rules templates” you find on GitHub. They’re written for generic projects and dilute the actual signal Claude needs about your code. Your own one-page rules file beats a 2000-line copy-paste every time.
Tool-wise, Cursor is the right pick over GitHub Copilot for any project where you want Claude in the loop. Strong rules support, real codebase context, and direct access to the Claude model lineup make it the cleanest setup for cursor private repo vs other AI coding tools work in 2026.
FAQ
Does Cursor send my private code to Anthropic?
With Privacy Mode enabled, Cursor passes prompts through to model providers, but neither Cursor nor the providers retain or train on your code [source-needed]. On the Business plan you get contractual zero data retention. For NDA work, also disable codebase indexing so file embeddings stay off Cursor’s servers entirely.
How is .cursor/rules different from .cursorrules?
The single .cursorrules file is the older format. The newer .cursor/rules/ directory supports multiple scoped files with YAML frontmatter, including path globs and always-apply flags. The directory format is more flexible and is the format Cursor recommends going forward in current documentation [source-needed].
Will cursor private repo rules slow down Cursor responses?
Slightly. Each rule adds tokens to the prompt, which costs a few hundred milliseconds per request and a small amount per call on metered plans. Keeping each rule file under 100 lines and scoping rules with globs keeps total overhead under one second in practice [test-claim].
Can I reuse these rules with Claude Code or other tools?
Partially. Claude Code reads CLAUDE.md files, not .cursor/rules. You can copy the content over, but the frontmatter and globbing are Cursor-specific. The stack and naming rules port directly; the response-style rules usually need slight rewording for each tool.
What if my repo has multiple stacks like frontend and backend?
Use path-scoped rules. One file with globs: apps/web/** for the frontend, another with globs: apps/api/** for the backend. Cursor loads only the rule matching the current file, so the prompt stays focused and Claude doesn’t mix conventions across the two stacks.
Is Cursor worth $20/month for a solo founder?
If you write code more than two hours a day, yes. The fast Claude requests alone save more time than the cost in the first week. If you only code occasionally, the free tier with your own API key plugged in is usually enough to evaluate before committing [verify pricing].
What to do next
Already using Claude for data work? See how to extract structured data from PDFs with Claude and Python — the same rules approach applies there.
- Open your repo and add a
.cursorignorewith the snippet above. Takes 30 seconds. - Create
.cursor/rules/00-base.mdcwith your stack, naming conventions, and three “don’t” rules. - Open one API route file, hit Cmd+K with a small change request, and confirm Claude cites your rule file in its response.