Worktrees w Cursor dają agentom osobne katalogi robocze, więc nie pracują na tej samej kopii plików. Nie zapobiega to jednak konfliktom podczas późniejszego łączenia zmian z różnych gałęzi Git. To ważne rozróżnienie: osobne miejsce pracy ogranicza wzajemne nadpisywanie plików, ale nie zastępuje integracji i przeglądu kodu.
Osobny katalog chroni przed pracą na tej samej kopii plików. Zgodność połączonych zmian trzeba ocenić osobno.
Co worktrees izolują, a co zostaje przy scalaniu
Worktree to osobny katalog roboczy powiązany z repozytorium i gałęzią Git. Agent pracujący w jednym worktree nie zapisuje zmian w katalogu drugiego agenta. Jeśli jednak oba agenty zmodyfikują tę samą część kodu na osobnych gałęziach, problem może pojawić się podczas ich scalania.
Git potrafi połączyć zmiany w różnych, nienakładających się fragmentach. Gdy zmiany obejmują te same linie, może wymagać ręcznego rozwiązania konfliktu. Nawet udane scalanie tekstowe nie gwarantuje poprawnego działania programu, dlatego po integracji nadal potrzebne są przegląd kodu i testy. Podręcznik Git wyjaśnia konflikty scalania.
Jak Cursor obsługuje worktrees
Cursor oferuje natywne worktrees w oknie Agents Window. W IDE opisuje natomiast Worktree Skills, w tym polecenia /worktree, /best-of-n, /apply-worktree i /delete-worktree. Polecenie /best-of-n uruchamia kandydatów w osobnych worktrees do porównania, ale samo nie scala ich zmian: trzeba wybrać wynik i zastosować go osobno. Dokumentacja Cursor opisuje oba przepływy.
Konfigurację przygotowania worktree można umieścić w pliku .cursor/worktrees.json. Obsługuje on ustawienia dla Unix, Windows lub ogólne, a polecenia mogą być zapisane jako tablica albo wskazywać skrypt. Cursor szuka pliku najpierw w katalogu worktree, a potem w głównym katalogu projektu.
Cursor może czyścić także ręcznie utworzone worktrees
W dokumentacji dotyczącej Cursor 3.5 i nowszych domyślny limit wynosi 25 worktrees na maszynę. Przykładowa konfiguracja podaje sześciogodzinny odstęp między porządkowaniem. Czyszczenie może objąć również katalogi utworzone ręcznie poleceniem git worktree add, więc samodzielne utworzenie worktree nie wyłącza go z tego procesu.
Co zrobić, gdy agent przerywa pracę przy zmianie worktree
10 września 2026 r. pracownik Cursor opisał zgłoszenie, w którym tworzenie worktree i zmiana katalogu głównego agenta w trakcie zadania mogły przerwać jego działanie. Jako rozwiązanie podał uruchomienie agenta od razu w katalogu, w którym ma pracować. Dodał też, że polecenie „continue” wznawia zatrzymane zadanie. Odpowiedź pracownika Cursor.