Switch Language
Toggle Theme

Complete Guide to Cursor Codebase Indexing: Principles, Configuration & @ Symbol Mastery

1 AM. Staring at the fifth wrong suggestion from Cursor, I finally lost it.

“Help me fix this login bug” — my request was crystal clear. But Cursor’s code? It had no idea I already had an auth utility function in my project. Instead, it wanted me to rewrite the entire validation logic from scratch. Worse, it suggested putting the code in a utils directory that didn’t even exist in my project.

That’s when it hit me: No matter how smart AI gets, if it can’t see the full picture of your project, it’s just a code-writing robot giving generic advice that never quite fits.

Later, I spent 20 minutes configuring Codebase indexing and a .cursorignore file. Tried again. Cursor got it instantly — not only did it find my auth utility, but it also spotted duplicate validation code scattered across three files and suggested consolidating them. That feeling of “AI finally understands my project” was incredible.

How Cursor Indexing Works Under the Hood

What is Codebase Indexing?

Honestly, when I first heard “indexing,” I was confused. Sounds sophisticated, but it’s actually simple once you get it.

Imagine going to a library to find a book. Without a catalog system, you’d have to scan shelf by shelf, potentially searching all day. But with a card catalog, typing in a title or keyword locates the exact position in seconds.

Cursor’s Codebase indexing works the same way — it builds an “intelligent catalog” for your entire project, allowing AI to quickly find relevant code instead of guessing blindly.

Specifically, indexing means scanning your code files, analyzing what each function, class, and variable does, then tagging them using a mathematical approach (vectorization). When you ask AI a question, it can instantly match the most relevant code snippets.

Six Key Steps of Indexing

I won’t bore you with all the technical details, but understanding this process helps you figure out why indexing sometimes slows down and why configuring .cursorignore matters.

Step 1: File Scanning and Preprocessing

When Cursor opens your project, it first scans all files. It skips files marked in .gitignore and .cursorignore — so if you haven’t configured .cursorignore, it might be diligently indexing your node_modules with tens of thousands of files.

Step 2: Code Chunking

After scanning, Cursor doesn’t treat entire files as one blob. It intelligently splits them by functions, classes, and logic blocks. A 1000-line utility file might be divided into 30 small chunks, each indexed independently. This gives better precision when querying.

Step 3: Vector Embedding (The Core)

This step is a bit abstract, but here’s the plain English: Vectorization converts code into a series of numbers, like a code “fingerprint.” Functionally similar code has similar fingerprints. Two different login functions, despite different implementations, are mathematically close in vector space.

Step 4: Building the Vector Database

All code chunk “fingerprints” are stored in a local database (Cursor uses technology like FAISS). This database is the index itself, saved on your computer, never uploaded to the cloud.

Step 5: Query Matching

When you type “help me optimize login logic,” Cursor vectorizes that sentence too, then searches the database for code blocks with the closest “fingerprints.” This process is incredibly fast — milliseconds.

Step 6: Context Injection

After finding relevant code, Cursor inserts these snippets into the AI’s context. The AI sees your actual code, so responses become much more accurate.

Why is Indexing So Important?

I ran a comparison test. Same requirement, without indexing: Cursor could only see my currently open file, giving suggestions that often missed the mark. With indexing enabled, it could relate 3-5 relevant files, providing solutions I could use immediately.

Current file + 1-3 manually @'d files
AI Understanding Without Indexing
Entire project + auto-related 10+ files
AI Understanding With Indexing
From 2 hours to 15 minutes
Cross-File Bug Fix Time
3x
Code Suggestion Accuracy Increase

The difference is huge. I had a cross-file bug involving three layers: API, data, and UI. Without indexing, I had to manually @ all three files and explain their relationships to the AI. With indexing, I simply asked “why isn’t user data updating?” Cursor found all three files on its own and even discovered a fourth one I’d missed (data validation in middleware).

Privacy and Security

Seeing terms like “cloud upload” and “AI analyzing code” makes many people nervous. I was too, initially.

Here are some facts to put your mind at ease:

  1. Code isn’t stored in plaintext — the index stores vectors (those number sequences), not your source code
  2. File paths are encrypted — even if someone gets the index file, they can’t tell what project it is
  3. Privacy mode — Cursor settings include a privacy mode where even vectors stay local

To be honest, for sensitive projects (like finance or healthcare), I’d enable Privacy mode. But for regular web projects or personal projects, default mode is totally fine and secure.

Complete Guide to @ Symbols

When I started with Cursor, I thought @ was just @, didn’t realize there’s so much to it. Using the wrong one not only wastes time but can make AI give absurd suggestions.

This chapter covers all 6 @ symbol types, their use cases, pros and cons. After reading, you’ll know exactly when to use which.

@Codebase - Project-Level Context

Purpose: Let AI understand your entire project’s code structure and logic.

This is the most powerful @ symbol, and the most underestimated. When you type @Codebase, Cursor uses the index database to automatically find all code snippets most relevant to your question.

Use Cases:

  • Cross-file troubleshooting: “Why isn’t data syncing after user login?”
  • Architecture-level questions: “Where does my project handle permission validation?”
  • Learning new projects: “How are routes organized in this project?”

My Real Experience: Once I inherited a legacy project — no documentation, thousands of files. I directly asked @Codebase how is the payment flow implemented? Cursor instantly pinpointed 5 relevant files, mapping the entire chain from API calls to data validation to callback handling. Manual code searching would’ve taken half a day.

Limitations:

  • Depends on index quality; poor indexing reduces effectiveness
  • Query speed is slower (typically 1-3 seconds) due to full database search
  • For massive projects (100k+ lines), some edge code might be missed

@Files - Precise File Reference

Purpose: Explicitly tell AI to focus on specific files.

This is the most straightforward. Type @Files, and a file selector pops up. You can check one or multiple files. AI only looks at your selected files, nothing else.

Use Cases:

  • You know exactly which files contain the problem
  • Need to modify specific file code
  • Avoid AI relating to irrelevant code

Real Case: I needed to refactor a component involving the component itself, style file, and test file. I used @Files to select all three, then asked “help me convert this component to functional style.” AI only looked at those three files, giving highly focused suggestions without noise.

Pros: Precise, fast, controllable
Cons: Requires knowing relevant files upfront, easy to miss some

@Folders - Directory-Level Reference

Purpose: Reference an entire folder’s code as context.

Useful when you know the problem is in a certain module but unsure which specific file.

Use Cases:

  • “Optimize all components in the /components/auth/ directory”
  • “Check the /api/ directory for security issues”
  • Batch processing code in a module

Caution: Too-large folders can exceed context limits. Generally, directories with 10 or fewer files work best. If a directory has dozens of files, AI might only see the first portion, truncating the rest.

@Code - Precise Code Snippet

Purpose: Reference a specific function, class, or code block.

This feature is cool. You can select a code section, right-click “Add to Chat,” or directly type @Code, then choose a function name.

Use Cases:

  • “This validateUser function has a bug, take a look”
  • “Refactor this logic to make it clearer”
  • Specify exact snippets during code review

My Favorite Use: In a 1000-line utility file, I only wanted AI to focus on one 50-line function. Using @Code to select that function means AI isn’t distracted by other code, focusing solely on that function’s issues.

@Docs - External Documentation Reference

Purpose: Let AI reference external docs like framework official documentation or API docs.

This feature was added to Cursor in late 2024, many people still don’t know about it.

Use Cases:

  • “Refer to Next.js official docs to help me configure dynamic routing”
  • “Generate calling code based on this API documentation”
  • When learning new tech, have AI combine docs with suggestions

How to Use: Type @Docs, then enter a documentation URL or select from Cursor’s built-in common framework docs.

Limitations:

  • Only supports some mainstream framework official docs
  • Custom documentation URLs sometimes fail (network issues or unsupported formats)

Purpose: Let AI search the web for latest information.

If you’re using a newly released library that hasn’t been trained into AI yet, use @Web to search for the latest usage.

Use Cases:

  • “Search for React 19’s latest features”
  • “Look up the latest version usage of this npm package”
  • Resolve newly appearing bugs or errors

Note: This feature is slightly slower since it searches the web in real-time. I only use it when I genuinely need the latest info.

Comparison Table: How to Choose Among 6 @ Symbols?

@ SymbolScopeSpeedUse CasesProsCons
@CodebaseEntire projectSlow (1-3s)Cross-file issues, learning projects, architecture questionsAuto-relates, comprehensiveDepends on indexing, may lack precision
@FilesSpecific filesFast (<1s)Know file locations, precise modificationsPrecise, controllableManual selection, easy to miss files
@FoldersEntire directoryMedium (1s)Module-level issues, batch processingModerate scopeToo large truncates
@CodeCode snippetFast (<1s)Function-level issues, code reviewExtremely focusedLacks broader context
@DocsExternal docsMedium (1-2s)Learning new tech, referencing official docsCombines authoritative sourcesLimited doc coverage
@WebWeb searchSlow (2-5s)Latest info, new library usageReal-time currentSlow, potentially inaccurate

My Usage Experience

Honestly, at first I only used @Files, thinking it was safest. Later I discovered that 80% of the time @Codebase is more efficient — letting AI find things itself is much faster than manual file selection, and it often discovers related code I overlooked.

My current usage frequency:

  • @Codebase: 60%
  • @Files: 30%
  • @Code: 5%
  • Others: 5%

You don’t need to copy this exactly — find your own rhythm. The key is understanding each @ symbol’s characteristics and which tool fits which scenario.

.cursorignore Configuration in Practice

Now we must talk about .cursorignore. This file may seem insignificant, but it can boost indexing speed by over 50% and cut CPU usage in half.

When I first used Cursor, I didn’t configure this file at all. Opening a project with node_modules, my computer fan went crazy, Cursor froze to the point I questioned reality. Later I learned it was diligently indexing 30,000 files in node_modules — all that third-party library code I didn’t need.

Why Do You Need .cursorignore?

Simple reason: Not all files are worth indexing.

Your project might contain:

  • Dependency files: node_modules, vendor, .venv, etc. — tens of thousands of files you basically never need
  • Build artifacts: dist, build, .next, etc. — all compiled output, not source code
  • Temporary files: .log, .cache, .DS_Store, etc. — completely irrelevant
  • Large static assets: videos, images, fonts — indexing them is useless

Excluding these can reduce indexing from 5 minutes to 30 seconds, and AI queries become more precise since they’re not distracted by irrelevant code.

.cursorignore vs .gitignore

Many ask: I already have .gitignore, do I still need .cursorignore?

Answer: Yes, and they serve different purposes.

.gitignore’s purpose is “which files not to commit to version control.” But some files you don’t want to commit, yet you want AI to see. For example:

  • Local config: .env.local you don’t commit, but AI needs to know your environment variables
  • Personal notes: TODO.md not committed, but AI can reference

Conversely, some files you commit but don’t need indexed:

  • package-lock.json: Needs committing, but AI doesn’t need to read this dependency lock file
  • Test coverage reports: Committed to CI, but no indexing needed

So .cursorignore needs separate configuration.

Universal Configuration Template (Copy and Use)

This is my universal template, suitable for most frontend projects. Create a .cursorignore file in your project root and copy this in:

# Dependency directories
node_modules/
.pnp/
.pnp.js
vendor/
.venv/

# Build artifacts
dist/
build/
.next/
out/
.cache/
.parcel-cache/

# Logs and temporary files
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.DS_Store
Thumbs.db

# IDE and editor configs
.idea/
.vscode/
*.swp
*.swo

# Test coverage
coverage/
.nyc_output/

# Static assets (optional, adjust per project)
*.mp4
*.avi
*.mov
*.zip
*.tar.gz

# Large JSON files (optional)
package-lock.json
yarn.lock
pnpm-lock.yaml

Note: This is just a base template, adjust for your project. If you use Python, add __pycache__/ and *.pyc.

Advanced Configuration Strategies

1. Staged Indexing for Large Monorepos

If your project is a monorepo with dozens of sub-packages, indexing everything might be slow. Use this strategy:

# Only index packages you're currently working on
packages/*/node_modules/
packages/package-a/  # Packages not currently focused on
packages/package-b/

When needed, uncomment them later.

2. Whitelist Mode

Sometimes project files are so messy that instead of listing exclusions, specify “only index these”:

# Exclude everything
*

# Only include src directory
!src/
!src/**/*

# Only include config files
!*.config.js
!tsconfig.json

This mode suits large legacy projects where you only want AI to focus on core code.

3. Filter by File Size

Cursor automatically skips oversized files (usually >1MB), but you can manually exclude:

# Exclude large data files
*.sql
*.csv
*.json  # If you have dozens of MB in JSON data

How to Verify Configuration?

After editing .cursorignore, verify it took effect. Two methods:

Method 1: Watch Indexing Speed

Close the project, reopen it, watch the “Indexing…” progress bar in the bottom right. Before configuration might take 3-5 minutes, after should finish in 30 seconds to 1 minute.

Method 2: Check Indexed File Count

In Cursor settings, search “Codebase Index,” it shows how many files are currently indexed. If it drops from 30,000 to a few hundred, configuration worked.

Method 3: Test @Codebase

Type @Codebase what files are in this project? and check the file list AI returns. If node_modules files still appear, .cursorignore didn’t take effect — check syntax.

Performance Optimization Results Comparison

I tested on a real Next.js project, here’s the data:

MetricBefore ConfigAfter ConfigImprovement
Indexed Files28,634487-98%
Indexing Time4m 23s41s-84%
Peak CPU Usage95%42%-56%
@Codebase Query Speed2.8s1.1s-61%

The data doesn’t lie. Configuring .cursorignore is step one in using Cursor effectively.

Common Issues and Solutions

Using Cursor for over a year, I’ve hit plenty of snags. Indexing failures, slow queries, CPU maxing out… these issues affect 90% of users.

This chapter compiles the 4 most common problems and solutions. When issues arise, follow this checklist, and you’ll basically solve everything.

Problem 1: Indexing Fails or Stuck on “Indexing…”

Symptoms:

  • Bottom right corner shows “Indexing…” for dozens of minutes without completing
  • Or displays “Indexing failed”
  • @Codebase has no response

Possible Causes and Solutions:

Cause 1: Too many project files, indexing timeout

  • Solution: Configure .cursorignore, exclude node_modules and other irrelevant files
  • Verify: Close project, reopen, check if indexing completes within 2 minutes

Cause 2: Unsupported or corrupted file format

  • Solution: Check for oversized files (>10MB) or binary files in project, manually add to .cursorignore
  • Common cases: Video files, large SQL dumps, compiled binaries

Cause 3: Insufficient disk space

  • Solution: Index data stores locally, check remaining disk space. Generally needs at least 5GB free
  • Mac path: ~/Library/Application Support/Cursor/
  • Windows path: %APPDATA%\Cursor\

Cause 4: Network issues (if cloud sync enabled)

  • Solution: Try disabling Privacy Mode or switch network environments
  • Temporary fix: Settings → Codebase Index → Enable “Local only mode”

Quick Troubleshooting Checklist:

☐ Check if .cursorignore is configured
☐ Check project file count (over 1000 needs optimization)
☐ Disk space sufficient (at least 5GB)
☐ Try restarting Cursor
☐ Delete old index cache, reindex

Problem 2: @Codebase Search Results Inaccurate

Symptoms:

  • Project clearly has relevant code, but @Codebase can’t find it
  • Or returns completely unrelated code

Possible Causes and Solutions:

Cause 1: Incomplete or outdated index

  • Solution: Manually trigger reindexing
  • Action: Cmd+Shift+P (Mac) / Ctrl+Shift+P (Windows) → Type “Reindex Codebase” → Enter

Cause 2: Code just written, not indexed yet

  • Solution: Cursor updates index in real-time but has 1-2 minute delay. After writing new code, wait a bit before querying
  • Or manually trigger index update

Cause 3: Question description too vague

  • Solution: Improve your question. Don’t ask “there’s a bug,” ask “why isn’t token saved to localStorage after user login”
  • Comparison:
    • ❌ “Optimize performance”
    • ✅ “List component renders slowly, find cause of repeated rendering”

Cause 4: Relevant code was excluded

  • Solution: Check .cursorignore, confirm core code wasn’t mistakenly excluded
  • Common mistake: Accidentally excluding entire src directory

Tips to Improve Accuracy:

  • Use specific function names, variable names, file names
  • Describe concrete business scenarios, not generalizations
  • If @Codebase isn’t accurate, try @Files to specify files directly

Problem 3: Cursor Using Too Much CPU/Memory

Symptoms:

  • Computer fan spinning wildly
  • Cursor using 80%+ CPU
  • Memory usage in the GBs
  • System lag

Possible Causes and Solutions:

Cause 1: Currently indexing large number of files

  • Solution: This is normal, wait for indexing to complete
  • If sustained high usage, configure .cursorignore to reduce indexed files

Cause 2: Real-time index updates too frequent

  • Solution: If you’re frequently modifying code, Cursor constantly updates index
  • Temporary fix: Settings → Codebase Index → Adjust “Update frequency” to “Manual” or “On save only”

Cause 3: Multiple large projects open simultaneously

  • Solution: Each project uses resources, close unneeded project windows

Cause 4: Corrupted index database

  • Solution: Delete index cache, reindex
  • Mac: Delete ~/Library/Application Support/Cursor/Index/
  • Windows: Delete %APPDATA%\Cursor\Index\

Performance Optimization Suggestions:

☐ Configure .cursorignore, reduce indexed files (target <1000 files)
☐ Close unneeded project windows
☐ Adjust index update frequency to "On save only"
☐ If project particularly large, consider using @Files instead of @Codebase
☐ Upgrade hardware (at least 16GB RAM, recommend 32GB)

Problem 4: @Codebase Response Very Slow

Symptoms:

  • After entering question, takes 5-10 seconds to respond
  • Sometimes times out

Possible Causes and Solutions:

Cause 1: Index database too large

  • Solution: Configure .cursorignore, reduce indexed files
  • Ideal state: 500-2000 indexed files, fastest query speed

Cause 2: Slow network (if using cloud model)

  • Solution: Check network connection or switch to local mode
  • Settings → Models → Choose lower-latency model

Cause 3: Queried code volume too large

  • Solution: @Codebase tries to include all related code, matching dozens of files slows it down
  • Optimize: Use more precise question descriptions or switch to @Files to specify scope

Cause 4: Insufficient computer performance

  • Solution: Vector search requires computational resources, low-spec computers will be slow
  • Recommended specs: At least 16GB RAM, SSD drive

Speed-Up Tips:

  • Prioritize @Files or @Folders, much faster than @Codebase
  • Regularly clean old index cache
  • Modularize projects, load only needed portions each time

My Troubleshooting Experience

When problems arise, don’t panic. 90% of indexing issues stem from not configuring .cursorignore, causing too many irrelevant files to be indexed.

My troubleshooting sequence:

  1. First check .cursorignore, confirm correct configuration
  2. Manually trigger reindexing, see if it resolves
  3. Check CPU/memory usage, determine if performance or configuration issue
  4. If nothing works, delete index cache, start fresh

Most problems get resolved following this sequence. If still not working, might be a Cursor bug itself — go to official GitHub to file an issue.

Real-World Case: Configuring Next.js Project Index from Scratch

Enough theory, let’s get practical. I’ll demonstrate using a real Next.js project, from creating .cursorignore to verifying results, complete walkthrough.

Follow along, 10 minutes to completion.

Configure Cursor Indexing for Next.js Project from Scratch

Complete workflow for configuring .cursorignore, verifying index status, testing @ symbol functionality

⏱️ Estimated time: 10 min

  1. 1

    Step1: Create .cursorignore file

    Create .cursorignore file in project root (same level as package.json).

    Terminal command:
    • touch .cursorignore (Mac/Linux)
    • type nul > .cursorignore (Windows)

    Recommended configuration for Next.js projects:

    # Next.js specific
    node_modules/
    .next/
    out/
    .cache/

    # Dependencies and lock files
    package-lock.json
    yarn.lock
    pnpm-lock.yaml

    # Build and temporary files
    dist/
    build/
    *.log
    .DS_Store

    # Test coverage
    coverage/
    .nyc_output/

    # IDE configs
    .vscode/
    .idea/

    # Static assets (adjust per project)
    public/images/*.mp4
    public/videos/

    Save file, close Cursor project, prepare to reopen for verification.
  2. 2

    Step2: Verify index status

    Three methods to check if configuration took effect:

    Method 1: Observe indexing progress
    • Close current project: File → Close Folder
    • Reopen project
    • Watch bottom-right "Indexing..." progress bar
    • Before config: 28,634 files, 3-5 minutes
    • After config: 487 files, 30-60 seconds

    Method 2: Check indexed file count
    • Open settings: Cmd+, (Mac) / Ctrl+, (Windows)
    • Search "Codebase Index"
    • Check "Indexed files" count
    • Dropping from tens of thousands to hundreds means it worked

    Method 3: Test @Codebase
    • Type: @Codebase what files are in this project?
    • Check returned list
    • If node_modules files still appear, check syntax
  3. 3

    Step3: Test @ symbol functionality

    Verify each @ symbol works properly.

    Test @Codebase:
    • Open chat: Cmd+L / Ctrl+L
    • Type: @Codebase How are page routes organized in this project?
    • Expected: Accurately finds route files in app/ or pages/ directory

    Test @Files:
    • Type: @Files
    • Select a page file (like app/page.tsx)
    • Ask: What does this page do?
    • Expected: Accurately interprets file functionality

    Test @Folders:
    • Type: @Folders app/components/
    • Ask: List all components in this directory
    • Expected: Returns component directory structure

    If all tests pass, configuration complete!
  4. 4

    Step4: Optimize configuration (optional)

    Further adjust .cursorignore based on actual needs.

    Exclude test files (if you don't need AI to see test code):
    __tests__/
    *.test.ts
    *.test.tsx
    *.spec.ts

    Exclude documentation and config files:
    README.md
    CHANGELOG.md
    *.config.js

    Whitelist mode (only index specific directories):
    # Exclude everything
    *

    # Only include source code directories
    !app/
    !app/**/*
    !src/
    !src/**/*
    !components/
    !components/**/*

    After adjusting, reopen project, verify indexed file count changes. Target: 500-2000 files for fastest query speed.

Case Summary: Before and After Configuration Comparison

I conducted complete testing on a real Next.js project (including component library, API routes, database integration):

MetricBefore ConfigAfter ConfigImprovement
Initial Indexing Time4m 23s41s84% faster
Indexed Files28,63448798% reduction
Peak CPU Usage95%42%56% lower
@Codebase Query Speed2.8s1.1s61% faster
AI Suggestion Accuracy (subjective)60%92%53% increase

That last metric “AI Suggestion Accuracy” was manually tested using 20 real development questions, comparing whether AI suggestions were usable. After configuring indexing, accuracy jumped from 60% to 92% — incredibly noticeable.

Key Takeaways

Through this real-world case, you should now know:

  1. ✅ How to create .cursorignore for Next.js projects
  2. ✅ How to verify if index configuration took effect
  3. ✅ How to test @ symbol functionality
  4. ✅ How to optimize configuration based on actual situations

This workflow isn’t just for Next.js — swap in React, Vue, Angular, or backend projects, the thinking is the same: Exclude irrelevant files, let AI focus on core code.

Conclusion

Wrapping up here.

Back to the opening scene — 1 AM, staring at Cursor’s fifth wrong suggestion. That frustration, many have felt it. No matter how powerful AI is, if it can’t see your project’s full picture, it can only guess.

Configuring indexing is the key to solving this.

Three core points to remember:

  1. Understanding principles isn’t for showing off, it’s to avoid getting burned. Knowing how indexing works helps you understand why node_modules must be excluded, why queries sometimes slow down, why AI sometimes can’t find code.

  2. .cursorignore is priority number one. Everything else can wait, this is essential. Indexing speed up 50%, CPU usage cut in half, AI accuracy up 60% — all real tested data.

  3. Don’t memorize @ symbols, understand use cases. 80% of the time @Codebase is enough, 20% of the time precisely use @Files. Don’t overthink it, you’ll get the feel with practice.

3 Steps to Take Immediately:

  1. Right now, go to your project root and create a .cursorignore file, copy the template from this article, save it
  2. Restart Cursor, watch indexing speed, feel the before-and-after difference
  3. Test @Codebase, ask a question AI struggled with before, see the results

That simple. 10 minutes invested saves hundreds of hours of efficiency later.

If this article helped you, share it with friends still struggling with Cursor indexing. We’ve all been through the pain — every pit avoided is a win.

That said, Cursor’s indexing functionality keeps evolving. This article is based on the January 2026 version, there might be new features and issues later. When encountering situations not covered here, check official docs for latest info.

Alright, stop just reading — go configure it.

FAQ

Why is node_modules still being indexed even though I configured .cursorignore?
Three possible reasons:

1. Syntax error: Check if .cursorignore file is saved as UTF-8 encoding, and paths end with slash (node_modules/ not node_modules)
2. Needs reindexing: After configuration, close and reopen project, or manually trigger reindexing (Cmd+Shift+P → Reindex Codebase)
3. Wrong file location: .cursorignore must be in project root (same level as package.json), not in subdirectories

Verification method: Open settings search "Codebase Index," check if indexed file count significantly decreased. If still tens of thousands, check the three points above.
@Codebase or @Files — which is better? When to use which?
Each has appropriate use cases, neither is universally better:

@Codebase suits:
• Cross-file troubleshooting (unsure which specific file)
• Learning new project code structure
• Architecture-level questions (like "how does project handle permission validation")

@Files suits:
• Know exactly which files have the problem
• Need precise modification of specific files
• Avoid AI being distracted by irrelevant code

Usage suggestion: 80% of the time try @Codebase first, if results are inaccurate or too slow, switch to @Files to specify files. My usage frequency is @Codebase 60%, @Files 30%, others 10%.
Indexing is very slow or keeps failing, how to quickly troubleshoot?
Follow this sequence to troubleshoot, 90% of problems resolve:

1. Check .cursorignore configuration: Ensure node_modules, dist, .next and other large directories are excluded
2. Check project file count: If over 1000 files, configuration isn't strict enough, needs further optimization
3. Check disk space: Ensure at least 5GB free (Mac path: ~/Library/Application Support/Cursor/)
4. Manually trigger reindexing: Cmd+Shift+P → Reindex Codebase
5. Delete old index cache: Close Cursor, delete index cache directory, reopen project

If none work, might be corrupted or oversized files (>10MB) in project, check and manually exclude.
Cursor using too much CPU, computer fan spinning wildly — what to do?
High CPU usage typically occurs during indexing, solutions:

Immediate relief:
• Wait for indexing to complete (first-time indexing uses more resources, normalizes after completion)
• Close unneeded project windows (each project uses resources)

Long-term optimization:
• Configure .cursorignore, reduce indexed files (target: under 1000 files)
• Adjust index update frequency: Settings → Codebase Index → Update frequency → Choose "On save only"
• Use whitelist mode: Only index src, app and other core directories
• Upgrade hardware: At least 16GB RAM, recommend 32GB

If sustained high usage after configuration, delete index cache and reindex. Mac path: ~/Library/Application Support/Cursor/Index/
What's the difference between .cursorignore and .gitignore? Can they be merged?
Different purposes, not recommended to merge:

.gitignore: Controls which files not to commit to version control
.cursorignore: Controls which files AI doesn't index

Typical differences:
• .env.local: Don't commit (.gitignore), but want AI to know environment config (not in .cursorignore)
• package-lock.json: Must commit (not in .gitignore), but AI doesn't need to see (in .cursorignore)
• TODO.md: Don't commit, but AI can reference

Suggestion: Maintain .cursorignore separately, configure based on "does AI need to see this file" principle, not simply copying .gitignore.
After configuring indexing, @Codebase query speed still very slow (5-10 seconds), is this normal?
5-10 seconds is not normal, normal speed should be within 1-3 seconds. Possible reasons:

1. Indexed file count still too high: Check indexed file count in settings, ideal range is 500-2000, over 5000 noticeably slows down
2. Question description too broad: @Codebase tries to match all related code, vague questions like "optimize performance" match dozens of files. Change to specific like "list component renders slowly, find repeated rendering cause"
3. Network latency (cloud model): Check network connection or switch to lower-latency model in settings
4. Insufficient computer performance: Vector search requires computational resources, recommend at least 16GB RAM + SSD

Speed-up tip: For definite files, using @Files directly is much faster (typically under 1 second).
How to configure indexing for monorepo projects? Indexing everything is too slow
Monorepo projects recommend staged indexing strategy:

Method 1: Only index currently working packages
# .cursorignore
packages/*/node_modules/
packages/package-a/ # Packages not currently working on
packages/package-b/
packages/package-c/

Method 2: Whitelist mode, only index specific packages
*
!packages/my-working-package/
!packages/my-working-package/**/*
!packages/shared-utils/
!packages/shared-utils/**/*

Method 3: Use Cursor's multi-workspace feature
• Don't open entire monorepo root
• Only open currently working sub-package directory
• When cross-package collaboration needed, separately @Files to reference

Real test: A 50-package monorepo, full indexing takes 10 minutes, indexing only 3 working packages takes just 1 minute.

18 min read · Published on: Jan 15, 2026 · Modified on: Feb 4, 2026

Comments

Sign in with GitHub to leave a comment

Related Posts