Cursor-Index-Governance in großen Projekten: Von der Diagnose bis zum vollständigen Neuaufbau

Letzte Woche habe ich einem Team ein Cursor-Engineering-Audit gemacht – ihr Monorepo hat über 200 Pakete. Jedes Mal beim Öffnen des Projekts: vier Sekunden Wartezeit beim Hover, durchschnittlich sechs Sekunden für Completions – eine Zeile tippen, einen Schluck Kaffee, warten. Zwei Tage lang: Hardware upgraden, Modell wechseln, Cursor neu installieren. Am Ende lag das Problem weder am Modell noch am Netzwerk, sondern daran, dass Cursor standardmäßig den gesamten packages/-Baum als Kontext behandelte. Dieser Artikel liefert Diagnose-Flow, Konfigurationsvorlagen und einen Neuaufbau-Plan – in zehn Minuten zurück zu flüssigem Cursor.

Cursor-Indexierung im Überblick – in 5 Minuten verstehen, warum es langsam wird

Im Hintergrund arbeitet der Merkle Tree. Cursor nutzt ihn, um Dateiänderungen zu verfolgen: Jede Datei erhält einen Hash, Ordner einen Hash aus den Kind-Hashes – bis zur Wurzel. Ändert sich eine Datei, ändern sich ihre Hashes und die der übergeordneten Ordner bis zur Wurzel. Cursor indexiert nur geänderte Dateien neu, nicht das ganze Repository.

Das Problem: In node_modules können 50.000 Dateien liegen – alle Hashes, allein die Hash-Daten ~3,2 MB. Schlimmer: Cursor berechnet Embeddings für diese Dateien – npm-Code, der wenig mit Ihrer Business-Logik zu tun hat, landet trotzdem im Kontext, weil der Indexer alles mitnimmt.

Laut Cursor-Blog braucht das 99. Perzentil großer Repos beim ersten Query ~4,03 Stunden. Im Team hilft ein versteckter Vorteil: Klonen desselben Repos sind zu ~92 % ähnlich – Cursor nutzt vorhandene Index-Daten und drückt den ersten Query oft auf ~21 Sekunden. Ist Ihr Index sauber, profitieren Kollegen von Ihrem Cache.

Kurz: Langsam ist selten die Rechenleistung – es sind zu viele, oft falsche Dateien im Index.

Diagnose – in 3 Schritten zum „Übeltäter“

Nicht sofort konfigurieren – zuerst diagnostizieren.

Schritt 1: Index-Status. Projekt öffnen, Icon unten rechts in der Statusleiste prüfen. Bleibt „Indexing…“ oder der Balken hängt? Cmd+Shift+P (Windows: Ctrl+Shift+P), „Show Cursor Logs“, letzte Zeilen lesen. Steht dort „Indexing 1,342 files…“ und die Zahl ist über 5.000? Das ist meist die Ursache.

Schritt 2: Verdächtige Ordner. Im Terminal im Projektroot:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

find . -type d -name "node_modules" -o -name "dist" -o -name "build" -o -name ".git" | wc -l

Typische „Index-Killer“:

Schritt 3: CPU und RAM. Activity Monitor (macOS) oder Task-Manager (Windows): Cursor-Prozess. CPU über 80 %, RAM über 4 GB? Dann rechnet der Index intensiv Hashes und Embeddings.

Entscheidungsbaum zur schnellen Zuordnung:

Laut Zest Troubleshooting Guide stammen ~90 % der Cursor-Instabilitäten von Extensions oder Index-Konfiguration – Sie sind sehr wahrscheinlich in der zweiten Kategorie.

.cursorignore – 3 Vorlagen für gängige Setups

Syntax wie .gitignore, Datei ins Repository-Root. Cursor indexiert ausgeschlossene Pfade nicht.

Vorlage 1: JavaScript/TypeScript

# Abhängigkeiten
node_modules/
.npm/
.yarn/

# Build-Artefakte
dist/
build/
out/
.next/
.nuxt/

# Tests und Coverage
coverage/
.nyc_output/

# Logs und Temporäres
*.log
*.tmp
.DS_Store

Bei Monorepo (z. B. pnpm workspace) phasenweise indexieren: alle Pakete aus, aktives Paket freigeben.

# Monorepo – phasenweise
packages/*/
!packages/api/        # aktuell bearbeitetes Paket
!packages/shared/     # Shared-Library
node_modules/
dist/

Vorlage 2: Python

# Virtuelle Umgebungen
venv/
.venv/
env/
.env/

# Bytecode-Cache
__pycache__/
*.pyc
*.pyo
.pytest_cache/

# Packaging
*.egg-info/
build/
dist/

# Jupyter
.ipynb_checkpoints/

venv/ allein kann den Index um ~90 % verkleinern.

Vorlage 3: Go

# Vendor
vendor/

# Build
bin/
*.exe
*.exe~
*.dll
*.so
*.dylib

# Tests
*.test
*.out
coverage.txt

vendor/ ähnelt node_modules/ – oft tausende Dateien.

Effekt: Developer Toolkit nennt ~65 % Kontext-Genauigkeit ohne .cursorignore (zu viel Rauschen) und ~98 % mit sinnvollen Ausschlüssen – weniger Dateien, deutlich bessere Treffer.

Monorepo: Multi-Root mit .code-workspace

Dutzende Services, jedes Mal auf den vollen Index warten? .code-workspace lädt nur die Pakete, an denen Sie gerade arbeiten.

workspace.code-workspace im Root:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

{
  "folders": [
    {"name": "payments", "path": "./services/payments"},
    {"name": "shared-libs", "path": "./libs"}
  ],
  "settings": {
    "cursor.indexing.maxFileSize": 512000,
    "cursor.chat.scopeSelection": "activeFolder"
  }
}

Cursor öffnet diese Datei (nicht das ganze Repo). Sidebar zeigt nur payments und shared-libs – Index nur dort, oft ~10× schneller.

Wichtige Settings:

• maxFileSize: 512000 – Dateien über 512 KB werden nicht indexiert (große JSON/CSV)
• scopeSelection: "activeFolder" – Agent-Kontext nur aus dem aktiven Ordner

Laut iamraghuveer können 10 Services à 5.000 Dateien 1–5 GB Index-Daten erzeugen – voll geladen belastet das System. Nur aktive Pakete: oft ~50 MB.

Wann Workspace statt nur .cursorignore?

• Monorepo mit 20+ relativ unabhängigen Paketen
• Sie arbeiten in einem Paket ohne ständige Cross-Package-Suche
• Team-Rollen sind klar getrennt

Bei starker Querabhängigkeit bleibt .cursorignore oft besser: Unnötiges raus, Benötigtes drin – ohne Workspace-Wechsel.

Cache leeren und Index neu aufbauen

Nach Config-Änderungen hängt der Index manchmal an alten Hashes – dann Cache bereinigen.

Schnell (zuerst)

Cmd+Shift+P, „Reindex Codebase“. Neu-Scan, oft Sekunden bis wenige Minuten bei großen Projekten. Statusleiste 0 % → 100 %.

Tief (wenn Schnellrebuild nicht reicht)

Cursor-Konfigurationsverzeichnis löschen:

Cursor schließen, Verzeichnis löschen oder sichern, Cursor neu starten – frische Config und Index.

⚠️ Hinweis: Löscht u. a. settings.json, Shortcuts, Extension-Settings. Vorher User/settings.json sichern.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Vollständiger Reset

1. Cursor schließen
2. ~/Library/Application Support/Cursor/User/settings.json sichern (falls vorhanden)
3. Gesamtes Config-Verzeichnis entfernen
4. Cursor starten, Index abwarten
5. settings.json zurückkopieren

Laut Zest löst Neustart → Cache → Status oft 80 % der Fälle in unter fünf Minuten; Tiefe Bereinigung nach .cursorignore-Änderungen, wenn der Index weiter falsch wirkt.

Wann neu indexieren?

• „Indexing…“ länger als 10 Minuten ohne Fortschritt
• Completions dauerhaft über 5 s statt 1–2 s
• Nach .cursorignore enthält @codebase noch ausgeschlossene Dateien

Fazit

Kernursache: zu viel Falsches im Index. Lösung: diagnostizieren, ausschließen, neu aufbauen.

Checkliste:

1. Großes Projekt öffnen, Cmd+Shift+P → „Show Cursor Logs“, Dateianzahl prüfen
2. Über 5.000 Dateien? Sofort .cursorignore (Vorlagen oben)
3. node_modules/, dist/, .git/ usw. ausschließen
4. „Reindex Codebase“ ausführen
5. Noch langsam? CPU/RAM prüfen, ggf. .code-workspace für aktive Pakete

Langfristig:

• Bei neuen Dependencies/Build-Setups .cursorignore mitpflegen
• .cursorignore ins Repo-Root für einheitliches Team-Setup
• In großen Monorepos inaktive Services aus dem Index halten

Probieren Sie es jetzt: In zehn Minuten spüren Sie oft wieder 1–2 s Completions, flüssiges @codebase und schnelle Hover-Hints.

Quellen

Daten und Zitate aus:

• Securely indexing large codebases - Cursor — Cursor-Blog, 2026-01-27
• Performance Optimization for Cursor - Developer Toolkit — Technik-Blog, 2026-05-28
• Cursor Codebase Indexing for Multi-Repo Workspaces - iamraghuveer — Blog, 2026-04-25
• A Practical Guide to Cursor Troubleshooting - Zest — Technik-Blog, 2025-12-24
• How to setup Cursor for Large Scale Repositories - NOVA AI — Technik-Blog, 2026-04-07