Menedżer git worktree
dla Claude Code, Codex i każdego CLI agentów

Git worktree to drugi checkout tego samego repozytorium, we własnym folderze i na własnej gałęzi, który dzieli historię i zdalne repozytorium z Twoim głównym checkoutem. Danie go każdemu agentowi AI do kodowania oznacza, że każdy agent edytuje, buduje i commituje własną kopię plików, więc dwóch agentów pracujących w tym samym czasie nigdy nie nadpisuje sobie nawzajem zmian ani nie przełącza sobie gałęzi pod nogami. Na naszym blogu jest dłuższy poradnik o stronie gita: Git worktrees: podstawa do uruchamiania wielu agentów AI bez konfliktów.

Tak. claude --worktree <nazwa> (albo -w) tworzy .claude/worktrees/<nazwa> na gałęzi o nazwie worktree-<nazwa>, kopiuje pliki ignorowane przez git wymienione w .worktreeinclude i przy wyjściu pyta, czy zachować, czy usunąć worktree; subagenty mogą działać we własnym worktree dzięki isolation: worktree. Nie instaluje Twoich zależności. W AgentsRoom możesz dalej z tego korzystać albo pozwolić, żeby o worktree prosił ticket lub agent, co dodatkowo go przygotowuje i pokazuje w zakładce Zmiany (sprawdzone na Claude Code 2.1.299).

Aplikacja Codex tak: tworzy zarządzane worktree w $CODEX_HOME/worktrees, w odłączonym HEAD (detached HEAD), kopiuje ignorowane pliki wymienione w .worktreeinclude, może uruchamiać skrypty konfiguracyjne lokalnego środowiska, trzyma 15 najnowszych i przenosi rozmowę między Local a worktree przez Handoff. codex-cli 0.162.1 ma flagę --worktree, która uruchamia sesję w nowym zarządzanym worktree. AgentsRoom daje agentowi Codex worktree tak samo jak każdemu innemu agentowi, z ticketu albo z okna Dodaj agenta.

Wszystkie: worktree to po prostu katalog roboczy agenta, niezależnie od tego, jakie CLI w nim działa, więc Claude, Codex, GitHub Copilot CLI, Cursor i 10 innych CLI agentów pracuje w nim tak samo. Kimi Code i Antigravity CLI ufają folderowi na podstawie jego dokładnej ścieżki; AgentsRoom przed uruchomieniem zapisuje dla nich nowy worktree jako zaufany, żeby nie zatrzymały się na pytaniu o zaufanie.

Nie. Zanim pierwszy agent wystartuje w nowym worktree, AgentsRoom kopiuje pliki ignorowane przez git z głównego checkoutu, które pasują do Pliki kopiowane z tego checkoutu (domyślnie każdy plik .env), i uruchamia polecenie instalacji wykryte na podstawie lockfile w katalogu głównym. Oba ustawiasz w Ustawienia projektu > Git > Przygotowuj nowe worktree, gdzie możesz zastąpić polecenie, na przykład przez pnpm install && pnpm build:deps. Plik, który już jest w worktree, nigdy nie jest nadpisywany.

Otwórz zakładkę Zmiany i wybierz worktree w selektorze Worktree u góry: lista plików, diffy, przegląd, Commit, Pull i Push działają wtedy na tym checkoucie. W przypadku ticketu opcja Automatycznie scal z bieżącą gałęzią po ukończeniu zadania scala jego gałąź, gdy przeniesiesz je do Done, a Automatycznie commituj po zakończeniu pracy (Ustawienia > Backlog) najpierw commituje to, co zostawił agent, więc scalenie obejmuje całą pracę.

W projekcie, w .worktrees/<gałąź>/, tworzone z domyślnej gałęzi zdalnego repozytorium, chyba że ustawisz Gałąź bazową worktree w Ustawienia projektu. Folder jest dodawany do .git/info/exclude klonu, nigdy do Twojego .gitignore, więc zostaje poza Twoimi commitami. Worktree nigdy nie są usuwane automatycznie: usuń jeden przez git worktree remove, gdy już go nie potrzebujesz.

Tak, w obu przypadkach. Na telefonie ekran Zmiany ma ten sam selektor Worktree, a ticket, który prosi o worktree, działa w nim, gdy uruchomisz je z telefonu, przygotowane przez komputer jak każde inne. Projekt otwarty na serwerze SSH ma swoje worktree na serwerze, bez kroku instalacji. Lokalny checkout, którego agenci działają na zdalnym hoście, nie może używać worktree, i ticket mówi Ci o tym, zamiast wystartować.