Strojenie Cursora pod duże repozytoria

Cursor zwalnia w dużych repozytoriach z czterech lokalnych powodów: indeks pełen wygenerowanego i dołączonego kodu, rozszerzenia, które się aktywują i konkurują o CPU, watcher plików i wyszukiwanie przechodzące przez wyniki budowania oraz serwer TypeScriptu z za małym limitem pamięci. Strojenie Cursora to usunięcie tych czterech przyczyn w tej kolejności i zmierzenie każdej zmiany przed i po, zamiast oceniania „na oko”.

Rano otwierasz monorepo z 12 pakietami. Podpowiedzi przychodzą z opóźnieniem, agent zwleka, zanim przeczyta pierwszy plik, wentylatory wyją, a wskaźnik indeksowania nie uspokoił się od ostatniego git pull. Zanim obwinisz model albo sieć, sprawdź, co Cursor naprawdę indeksuje, obserwuje i uruchamia na twojej maszynie. Tę część naprawiasz sam, a poprawka ląduje w plikach, które możesz zacommitować.

Ta strona jest dla programisty, któremu zwalnia edytor, i dla tech leada, który chce zapisać poprawkę raz dla całego zespołu. Jeśli wolna jest aplikacja, a nie edytor, przejdź do profilowania i naprawy wydajności aplikacji z Cursorem.

Co daje strojenie Cursora

• .cursorignore zbudowany na podstawie rzeczywistej liczby plików w twoim repozytorium, a nie z ogólnego szablonu.
• Zacommitowany .vscode/settings.json, dzięki któremu watcher plików i wyszukiwanie omijają wyniki budowania.
• Audyt rozszerzeń z powtarzalnym sposobem na znalezienie tego jednego, które zjada CPU.
• Tabelę pomiarów „przed i po”, która dowodzi, że strojenie zadziałało, oraz test sprawdzający, że agent nadal znajduje twój kod.

Jak zmierzyć punkt wyjścia przed zmianami?

Strojenie bez punktu odniesienia zamienia się w zgadywanie. Zrób teraz pięć odczytów, zapisz je i powtórz te same pięć po każdej zmianie.

1. Liczba zaindeksowanych plików. Otwórz Cursor Settings i znajdź sekcję indeksowania bazy kodu. Zapisz liczbę zaindeksowanych plików.

2. Czas startu. Uruchom Developer: Startup Performance z palety poleceń (Cmd/Ctrl+Shift+P). Zapisz łączny czas do gotowego okna.

3. Aktywacja rozszerzeń. Uruchom Developer: Show Running Extensions. Lista pokazuje każde aktywne rozszerzenie z czasem aktywacji. Zapisz pięć najwolniejszych.

4. Pamięć i CPU procesów. Uruchom Developer: Open Process Explorer. Zapisz pamięć i CPU procesu rozszerzeń (extension host), watchera plików i serwera TypeScriptu (tsserver).

5. Czas do pierwszej akcji agenta. Otwórz nowy czat z agentem i za każdym razem wyślij ten sam prompt, na przykład „Find where user sessions are created and list the files”. Zmierz, ile trwa otwarcie pierwszego pliku.

Potem zmierz samo repozytorium w terminalu, w katalogu głównym repo. Te polecenia git pokazują, gdzie są pliki:

# Śledzone pliki w każdym katalogu najwyższego poziomu, od największej liczby
git ls-files | cut -d/ -f1 | sort | uniq -c | sort -rn | head -20

# Ignorowane lub nieśledzone katalogi na dysku (wyniki budowania, cache)
git ls-files --others --ignored --exclude-standard --directory | head -30

# 20 największych śledzonych plików, w KB
git ls-files -z | xargs -0 du -k 2>/dev/null | sort -rn | head -20

Wynik pierwszego polecenia zwykle zaskakuje. Wygenerowane klienty API, snapshoty testów, dołączone SDK i dane testowe (fixtures) są w repozytorium, więc .gitignore ich nie ukrywa, a często jest ich więcej niż kodu, który piszesz.

Jak odchudzić indeks plikiem .cursorignore?

.cursorignore używa składni .gitignore i leży w katalogu głównym repozytorium. Kod agenta Cursora czyta zarówno .gitignore, jak i .cursorignore (sprawdzone w @cursor/sdk 1.0.32, 2026-09-26). Katalog, który .gitignore już pomija, nie potrzebuje więc drugiego wpisu. .cursorignore służy do plików, które commitujesz, ale nie chcesz, żeby trafiały do indeksu i były czytane przez agenta.

Punkt wyjścia dla monorepo w TypeScripcie, złożony z typowych ścieżek, które znajdują powyższe polecenia:

# Zacommitowany kod generowany
**/__generated__/
**/*.generated.ts
packages/api-client/src/gen/
prisma/generated/

# Snapshoty testów i duże pliki z danymi testowymi
**/__snapshots__/
tests/fixtures/large/

# Dołączony lub zminifikowany kod zewnętrzny
vendor/
**/*.min.js
**/*.min.css

# Lockfile’y: duże i rzadko przydatne jako kontekst
pnpm-lock.yaml
package-lock.json
yarn.lock

Nie wpisuj lockfile’ów do .cursorignore, jeśli agent ma odpowiadać na pytania o zainstalowane wersje zależności. Dodawaj linię tylko wtedy, gdy uzasadnia ją liczba plików z poleceń. Nigdy nie wykluczaj kodu źródłowego (src/, lib/, app/), testów, które agent ma rozbudowywać, ani konfiguracji, którą musi czytać. Wykluczony plik jest dla agenta niewidoczny, a agent, który nie widzi twojego kodu, pisze go od nowa.

Po edycji pliku uruchom ponowną synchronizację w sekcji indeksowania w Cursor Settings i poczekaj, aż liczba plików się ustabilizuje. Zapisz nową liczbę obok poprzedniej.

Strategię dla całego monorepo, na przykład otwieranie tylko potrzebnych pakietów jako workspace z wieloma katalogami, opisuje praca z dużymi bazami kodu. Ta strona zajmuje się kosztem samego edytora.

Prompt do skopiowania: propozycja .cursorignore oparta na danych

Audit this repository for files that should be excluded from Cursor's index.

1. Run these from the repo root and show me the output:
   git ls-files | cut -d/ -f1 | sort | uniq -c | sort -rn | head -20
   git ls-files -z | xargs -0 du -k 2>/dev/null | sort -rn | head -20
2. For each directory or pattern that holds generated code, snapshots,
   fixtures, vendored or minified code, open two sample files to confirm
   what they are. Look for "generated" or "do not edit" headers.
3. Propose a .cursorignore. For every line give: the pattern, the number
   of files it removes, and one sentence of evidence.
4. Do NOT propose excluding src/, lib/, app/, tests you would extend, or
   any config file. List anything you were unsure about separately.

Do not write the file. Show me the proposal first.

Jak wyłączyć watcher i wyszukiwanie z wyników budowania?

Cursor dziedziczy watcher plików i wyszukiwanie po VS Code, a oba mają własne listy wykluczeń, na które .cursorignore nie wpływa. Umieść ustawienia w .vscode/settings.json i zacommituj je, żeby każdy w zespole miał ten sam efekt:

{
  "files.watcherExclude": {
    "**/dist/**": true,
    "**/build/**": true,
    "**/.next/**": true,
    "**/coverage/**": true,
    "**/.turbo/**": true
  },
  "search.exclude": {
    "**/dist": true,
    "**/build": true,
    "**/coverage": true,
    "**/*.min.js": true,
    "**/*.map": true
  },
  "typescript.tsserver.maxTsServerMemory": 6144
}

• files.watcherExclude wycisza zdarzenia zmian z katalogów budowania i testów. Domyślna lista VS Code obejmuje już .git/objects i .git/subtree-cache, więc dopisujesz tylko własne katalogi wynikowe.
• search.exclude trzyma wyszukiwanie tekstowe edytora z dala od tych samych katalogów, więc wyniki i proces wyszukiwania pozostają małe.
• typescript.tsserver.maxTsServerMemory podnosi limit pamięci serwera TypeScriptu z domyślnych 3072 MB. Podnoś go tylko wtedy, gdy Process Explorer pokazuje tsserver blisko limitu albo serwer się restartuje. Gałąź main VS Code oznacza typescript.tsserver.maxTsServerMemory jako przestarzały na rzecz js/ts.tsserver.maxMemory (oba mają domyślnie 3072, sprawdzone 2026-09-26). Wpisz maxMemory w wyszukiwarce ustawień i użyj klucza, który twoja wersja Cursora pokazuje bez przekreślenia oznaczającego wycofanie.

Starsze poradniki polecają też files.maxMemoryForLargeFilesMB. VS Code usunął to ustawienie, więc nic już nie robi (brak go w files.contribution.ts na gałęzi main VS Code, sprawdzone 2026-09-26).

Jak znaleźć rozszerzenia, które zjadają CPU?

Każde zainstalowane rozszerzenie VS Code działa w procesie rozszerzeń Cursora. Jedno zajęte rozszerzenie potrafi spowolnić podpowiedzi, edycje agenta i zapisywanie plików w całym oknie.

1. Otwórz Developer: Show Running Extensions i przejrzyj czasy aktywacji. Kandydatem jest wszystko, co aktywuje się przy starcie (*) i zajmuje setki milisekund.

2. Wyłącz rozszerzenia językowe dla języków, których ten workspace nie używa. Użyj Disable (Workspace) w widoku Extensions, żeby rozszerzenie nadal działało w innych projektach.

3. Zostaw usługi językowe, od których zależy projekt. Wyłączenie TypeScriptu, ESLinta albo serwera języka twojego projektu odbiera agentowi diagnostykę, którą czyta, sprawdzając własne edycje.

4. Jeśli spowolnienie zostaje, a przyczyny nie widać, uruchom Help: Start Extension Bisect. W każdej rundzie wyłącza połowę rozszerzeń i pyta, czy problem nadal występuje, aż wskaże winowajcę.

5. Zapisz rozszerzenia, których zespół nie powinien instalować, w .vscode/extensions.json pod kluczem unwantedRecommendations, żeby decyzja przetrwała dłużej niż twoja maszyna.

Prompt do skopiowania: lista rozszerzeń jako polityka workspace’u

I will paste the output of "Developer: Show Running Extensions" below.

For this repository:
1. Detect which languages and tools are really used (file extensions,
   package.json, pyproject.toml, Dockerfile, CI config).
2. Classify each running extension as KEEP (needed for a language or tool
   in this repo), DISABLE-HERE (not used in this repo), or INVESTIGATE
   (activation time over 300 ms or activates on startup).
3. Write a .vscode/extensions.json with "recommendations" for the KEEP set
   and "unwantedRecommendations" for the DISABLE-HERE set.
4. Never put the TypeScript, ESLint or test-runner extensions this repo
   uses in the DISABLE-HERE list.

Show the table first, then the file.

<paste the Running Extensions list here>

Jak nie mnożyć kosztu przez worktree?

Lokalne równoległe agenty Cursora mogą pracować w worktree Gita, co opisuje strona Okno Agents i Projects w Cursorze, a każde worktree to pełny checkout, który potrzebuje własnych zależności. Trzy nawyki ograniczają ten koszt:

• Instaluj zależności menedżerem pakietów, który korzysta z globalnego magazynu, na przykład pnpm, bun albo uv, żeby nowe worktree linkowało pakiety zamiast pobierać je od nowa.
• Instaluj zależności w każdym nowym worktree, zanim agent zacznie pracę. Cursor potrafi tworzyć worktree dla swoich agentów; zacommituj jeden skrypt przygotowania, który każdy agent uruchamia na początku (przykład znajdziesz na stronie o oknie Agents).
• Sprzątaj samym Gitem. git worktree list pokazuje wszystkie checkouty, a git worktree prune usuwa wpisy o worktree, których katalogów już nie ma.

Jak udowodnić, że strojenie zadziałało?

Powtórz pięć odczytów z punktu wyjścia i zestaw je obok siebie. Zmiana, która nie ruszyła żadnego z nich, nie dotyczyła wąskiego gardła. Wycofaj ją i trzymaj konfigurację małą.

Odczyt	Gdzie	Jak wygląda poprawa
Zaindeksowane pliki	Cursor Settings, sekcja indeksowania	Spadek mniej więcej o tyle plików, ile obiecywały linie .cursorignore
Czas startu	Developer: Startup Performance	Krótszy albo bez zmian, jeśli przyczyną nie były rozszerzenia
Najwolniejsze rozszerzenia	Developer: Show Running Extensions	Nic niewyjaśnionego nie aktywuje się przy starcie
Proces rozszerzeń, watcher, tsserver	Developer: Open Process Explorer	Niższe CPU w spoczynku; tsserver poniżej limitu pamięci
Czas do pierwszej akcji agenta	Twój stały prompt	Krótszy, a agent znajduje te same pliki

Szybkość to tylko połowa sprawdzenia. Druga połowa to pewność, że agent nadal widzi wszystko, czego potrzebuje. Po każdej zmianie .cursorignore uruchom test:

Prompt do skopiowania: czy agent nadal znajduje kod

Without asking me for paths, find and open each of these, and tell me the
file and line where you found it:
1. The function that creates a user session
2. The main HTTP router or route table
3. The database schema or migration directory
4. One test file that covers the billing or payments code
5. The CI workflow that runs the test suite

If you cannot find any of them, say which one and list the ignore
patterns (.gitignore, .cursorignore) that might be hiding it.

Zamień pięć celów na pięć, które liczą się w twoim repozytorium, i dołącz listę do pull requesta zmieniającego .cursorignore. Tech lead przegląda taki pull request jak każdą zmianę konfiguracji: dane o liczbie plików, tabela „przed i po” i zaliczony test są akceptacją, a nikt nie musi czytać wzorców linia po linii.

Co robić, gdy strojenie Cursora nie pomaga?

Liczba zaindeksowanych plików prawie się nie zmieniła. Duże katalogi są prawdopodobnie w repozytorium, więc .gitignore nigdy ich nie obejmował, a twój wzorzec w .cursorignore do nich nie pasuje. Uruchom ponownie polecenie liczące pliki, porównaj ścieżki dokładnie ze wzorcami i zsynchronizuj indeks.

Agent pisze kod, który już istnieje. Wykluczyłeś za dużo. Uruchom prompt testowy, znajdź wzorzec, który ukrywa brakujący plik, zawęź go i zsynchronizuj indeks.

Z kontroli agenta zniknęła diagnostyka albo błędy typów. Wyłączyłeś rozszerzenie językowe, którego projekt potrzebuje. Włącz je z powrotem dla workspace’u i uruchom Developer: Reload Window.

tsserver ciągle się restartuje. Process Explorer pokazuje go na limicie pamięci. Podnieś typescript.tsserver.maxTsServerMemory (albo js/ts.tsserver.maxMemory) i uruchom TypeScript: Restart TS Server. Jeśli to nie pomaga, zawęź include w tsconfig.json albo podziel repozytorium przez project references, bo serwer ładuje więcej niż pakiet, nad którym pracujesz.

Edytor jest szybki, ale agent wolny. Lokalne wąskie gardło zniknęło. Zostaje wywołanie modelu, sieć albo rozmiar wysyłanego kontekstu. Rozmiar kontekstu opisuje zarządzanie tokenami, a kompromisy między modelami wybór modelu.

Worktree zapychają dysk. Uruchom git worktree list, usuń te, których gałęzie są już scalone, poleceniem git worktree remove <path>, a potem git worktree prune.

Uwaga

.cursorignore trzyma pliki poza indeksem i z dala od agenta, ale nie jest mechanizmem ochrony sekretów. Trzymaj poświadczenia poza repozytorium i poza środowiskiem agenta. Jak sprawdzić bazę kodu pod kątem wycieku sekretów, opisuje audyt bezpieczeństwa w Cursorze.

Dokąd dalej po strojeniu Cursora?

• Niezbędna konfiguracja to punkt wyjścia: ustawienia, od których zaczyna się każdy projekt w Cursorze.
• Praca z dużymi bazami kodu opisuje nawyki, dzięki którym duże repozytorium pozostaje łatwe do opanowania: zawężone prompty, reguły i workspace’y w monorepo.
• Zarządzanie tokenami pokazuje, jak ograniczyć wysyłany kontekst, co skraca też odpowiedzi.
• Przegląd eksploatacji Cursora oddziela wydajność edytora od wydajności aplikacji, bezpieczeństwa i monitoringu.
• Używasz też Claude Code? Zobacz strojenie wydajności i kosztów Claude Code.