OpenCode naprawia błąd, a ty zachowujesz swój katalog roboczy

Masz w katalogu roboczym w połowie napisaną zmianę, kiedy ktoś zgłasza błąd parsera dat. Chcesz nadal edytować swoje pliki, a agentowi programistycznemu dać osobne zadanie. Gdy oboje zaczynacie pracę w tym samym katalogu, nawet niewielką poprawkę trudno odróżnić od zmian, nad którymi jeszcze pracujesz.

6 listopada OpenCode 2.2.6 dodał opcję worktree do uruchomień z wiersza poleceń wywoływanych ze skryptu. OpenCode to otwarty agent programistyczny z interaktywnym interfejsem terminalowym i osobną komendą do wykonywania polecenia ze skryptu. Nowa opcja pozwala zacząć w oddzielnym katalogu roboczym Git, opcjonalnie go nazwać i nadal korzystać z pierwotnego katalogu. To samo wydanie dodało opcjonalne współdzielenie zgodnych połączeń Model Context Protocol (MCP). Przed uruchomieniem warto więc ustalić dwie rzeczy. Które pliki agent może zmienić i z jakich usług może skorzystać? Wydanie OpenCode v2.2.6 · Dokumentacja CLI OpenCode

Najbardziej praktyczna konfiguracja łączy małe zadanie z przewidywalnym punktem początkowym, osobnym miejscem do kontroli zmian i jasno określonymi uprawnieniami do działań poza projektem.

Zrzut terminala projektu OpenCode pokazuje poprawkę i sesję w interfejsie. Materiał marki z oznaczonego wydania ilustruje pracę w terminalu. Do obrazu dołączono informację o licencji MIT. Telli.sh przeskalował zrzut i dodał margines.

W oddzielnym katalogu widać zmiany samego agenta

Oddzielny katalog roboczy Git daje każdemu zadaniu własne pliki i indeks. Ilustracja Telli.sh.

Git pozwala połączyć więcej niż jeden katalog roboczy z repozytorium. Każdy ma własne pliki robocze, indeks i bieżącą pozycję w historii. Większość danych repozytorium jest współdzielona. Możesz obejrzeć poprawkę agenta, a twoje zmiany zostają na miejscu. Rozdzielenie zmienia też to, jaki kod widzi agent. Niezatwierdzone zmiany z pierwszego katalogu nie pojawiają się w drugim tylko dlatego, że oba należą do jednego repozytorium. Dokumentacja Git worktree

Wydanie OpenCode z 6 listopada opisuje trzy sposoby włączenia tej funkcji. Użyj opencode run -w lub opencode run --worktree, aby utworzyć nowy katalog, albo --worktree=<name>, aby go nazwać. Dokumentacja mówi również, że tej opcji nie można łączyć z --continue ani z --session. Czyste uruchomienie wymaga nowego kontekstu. Jeśli zgłoszenie ma już długą historię rozmowy, przenieś do nowego polecenia kroki odtworzenia i oczekiwany wynik. Wydanie OpenCode v2.2.6 · Implementacja i przykłady worktree

Traktuj osobny katalog jako miejsce przeglądu. Przed rozpoczęciem zapisz gałąź i zatwierdzenie, od których agent ma zacząć. Po uruchomieniu sprawdź pozycję i stan utworzonego katalogu. Jeżeli test zależy od pliku spoza kontroli wersji albo od zmiany istniejącej tylko w edytorze programisty, różnica w punkcie startowym wyjaśnia pozorną rozbieżność wyników. Poprawka może być właściwa dla starszego kodu, a mimo to nie pasować do gałęzi przygotowywanej do wydania.

Wypróbuj jedną małą zmianę przed przekazaniem większego zadania

Zacznij od własnego repozytorium i konkretnego zadania. Test kończący się niepowodzeniem dla 29 lutego nadaje się do pierwszej próby lepiej niż obszerna aktualizacja, bo łatwo zweryfikować wynik. Podobnie ograniczonym zadaniem jest poprawienie nieaktualnego odsyłacza z jednym testem ścieżki. W obu przypadkach jasno opisz, co ma działać inaczej i jak to sprawdzisz.

1. Zapisz stan początkowy. W bieżącym katalogu wykonaj git status --short i git rev-parse HEAD. Zachowaj wynik przy zgłoszeniu błędu. Jeśli masz już przechodzącą próbę odniesienia, zapisz sposób jej odtworzenia. Wykonaj opencode --version, aby sprawdzić, czy wersja zawiera nową opcję. Wydanie OpenCode v2.2.6

2. Daj agentowi jedno zadanie z nazwanym katalogiem. Umieść sposób odtworzenia i test docelowy w poleceniu. Przykład dotyczy fikcyjnego parsera dat i zakłada, że repozytorium zawiera odpowiedni test. Prośba o pozostawienie niezatwierdzonych zmian ułatwia kontrolę. Mocniejsze ograniczenia wprowadź w uprawnieniach i środowisku uruchomieniowym.

   ShellUruchom w: Terminal

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. Odszukaj nowy katalog przed przeglądem wyniku. W pierwotnym repozytorium wykonaj git worktree list i przejdź do podanej ścieżki. W nowym katalogu sprawdź git status --short, git diff i git diff --cached. Ostatnie polecenie jest ważne, jeśli agent dodał zmiany do indeksu. Obejrzyj osobno pliki nieśledzone. Uruchom samodzielnie właściwe testy z katalogu agenta. Sprawdź, czy obejmują 29 lutego w roku przestępnym oraz rok, w którym ta data jest niepoprawna. Dokumentacja Git worktree

4. Przenieś wyłącznie sprawdzoną pracę. Zachowaj proponowaną zmianę oddzielnie, dopóki nie można przenieść sprawdzonej poprawki lub zatwierdzenia na docelową gałąź. Ponownie sprawdź stan pierwotnego katalogu. Zachowaj katalog agenta do czasu zapisania potrzebnych informacji i potwierdzenia, że nie ma w nim zmian, które chcesz zatrzymać. Lista katalogów Git pozwala ustalić, który z nich należy do którego zadania. Dokumentacja Git worktree

Ten sam sposób pracy pomaga, gdy naraz pojawią się dwa niepowiązane zgłoszenia. Ogranicz zakres obu i porównaj poprawki przed połączeniem. Osobne katalogi sprawią, że zmiana testu, której jeden agent nie dodał do indeksu, nie pojawi się w drugim katalogu. Poprawki nadal mogą kolidować na wspólnej gałęzi, zwłaszcza gdy dotykają tej samej funkcji pomocniczej. Integracja i końcowe testy regresji nadal należą do zwykłego procesu przeglądu.

Ustal, kto i co może robić poza repozytorium

Dwa katalogi robocze mogą działać na tym samym koncie systemowym. Mogą mieć wspólne środowisko, narzędzia do obsługi danych uwierzytelniających i sieć. Nowa opcja określa początkowy katalog i oddziela zwykłe zmiany robocze. Gdy potrzebujesz mocniejszych granic, ogranicz środowisko lub konto oddzielnie. Pytanie o zgodę wpływa na narzędzia, które je respektują, a system operacyjny lub środowisko wykonania określa, do czego proces faktycznie ma dostęp.

Oddziel miejsce zmian, zgody na użycie narzędzi i dostęp w środowisku wykonania. Ilustracja Telli.sh.

Dokumentacja uprawnień OpenCode V2 opisuje uporządkowane reguły dla poszczególnych akcji. Skutki obejmują allow, ask i deny, a ostatnia pasująca reguła ma pierwszeństwo. Oficjalny przykład wymaga zgody przed poleceniami powłoki, pozwala na typowe polecenia odczytu i blokuje wysyłanie zmian do zdalnego repozytorium. Jeśli zadanie ma działać bez osoby zatwierdzającej, sprawdź zachowanie ask w tym trybie przed ustawieniem cyklicznego uruchomienia. Zapisz zakazy w konfiguracji i używaj krótkotrwałych danych uwierzytelniających o małym zakresie dla usług, których zadanie potrzebuje. Dokumentacja uprawnień OpenCode

Te warstwy można wypróbować na zmianie samej dokumentacji. Pozwól agentowi edytować jedną sekcję przykładowego projektu. Udostępnij dozwolonego dostawcę modelu bez produkcyjnych danych uwierzytelniających. Uruchom skrypt i sprawdź, czy poprawka dotyka tylko oczekiwanego pliku. Jeśli później automatyzacja potrzebuje zdalnego repozytorium lub systemu zgłoszeń, określ cel każdego uprawnienia i zweryfikuj je osobno.

Współdzielenie ma sens dla projektów o wspólnych granicach dostępu

MCP pozwala agentowi używać narzędzi dostarczanych przez inne programy, na przykład wyszukiwarki dokumentacji albo systemu zgłoszeń. W wydaniu z 6 listopada pool: true pozwala katalogom obsługiwanym przez jeden serwer OpenCode ponownie użyć połączenia, jeśli odpowiednia konfiguracja jest zgodna. Oficjalna dokumentacja V2 wskazuje rewizję protokołu 2026-07-28. Jeśli serwer uzgodni starszą rewizję, połączenia pozostają osobne. Wskazanie tego samego adresu nie wystarcza. Muszą się zgadzać ustawienia połączenia zdalnego i uwierzytelnione konta. Przy serwerze lokalnym dopasowanie obejmuje polecenie, środowisko i katalog roboczy. Wydanie OpenCode v2.2.6 · Współdzielenie MCP w OpenCode

Wyobraź sobie dwa katalogi, które z tego samego konta odpytywałyby wewnętrzną dokumentację. Wspólne połączenie ogranicza powielanie konfiguracji, jeśli usługa obsługuje odpowiednią rewizję. Najpierw potwierdź, że oba katalogi powinny mieć dostęp do tych samych materiałów i że integracja daje tylko potrzebne możliwości. Gdy jeden katalog potrzebuje wyłącznie publicznych dokumentów, a drugi otwiera również wewnętrzne zgłoszenia, osobne połączenia ułatwiają sprawdzenie granic.

Serwer lokalny może zależeć od bieżącego katalogu. Procesy uruchomione w katalogach różnych projektów mogą mieć inny kontekst mimo identycznego polecenia. Według dokumentacji OpenCode przy współdzieleniu lokalnych połączeń między projektami katalog roboczy musi być stały, a współdzielone połączenie nie ma korzeni MCP. Warto zacząć od usługi tylko do odczytu o jasno określonych zasobach. Jeśli działanie narzędzia zależy od repozytorium wywołującego, zmierz różnice przed włączeniem współdzielenia. Współdzielenie MCP w OpenCode

Uruchomienie ze skryptu też musi się kiedyś skończyć

OpenCode 2.2.6 dodał również --archived, aby sesje skryptowe lub CI mogły od początku trafiać do archiwum i nie pojawiać się na zwykłych listach. To zmienia sposób ich prezentacji. Zapisuj wynik, ścieżkę katalogu i rezultaty testów w miejscu dostępnym dla sprawdzających. Używaj opcji, gdy możesz znaleźć właściwą poprawkę nawet bez zwykłej listy. Według informacji o wydaniu z 6 listopada --continue pomija sesje zarchiwizowane. Wydanie OpenCode v2.2.6

To samo wydanie zmienia moment zakończenia skryptu. Czeka na polecenia w tle, podagentów i zadania obrazowe uruchomione przez instrukcję. Według opisu nie ma wewnętrznego limitu oczekiwania, więc serwer deweloperski albo obserwator plików może utrzymywać proces. Do testu automatycznego wybierz polecenia, które kończą się wraz ze sprawdzeniem, i ustaw limit czasu kroku CI. Rozróżniaj anulowane uruchomienie, nieudany test i zgłoszenie sukcesu przez agenta. Gdy czas się skończy, ustal rzeczywisty stan zmiany przed ponowieniem lub integracją. Wydanie OpenCode v2.2.6

Po udanej próbie możesz ocenić, czy agent faktycznie oszczędza czas. Zmierz przygotowanie uruchomienia, zrozumienie i sprawdzenie zmiany, cofanie niepowiązanej edycji i badanie zatrzymanego narzędzia. Porównaj kilka podobnych zadań z uwzględnieniem konfiguracji i przeglądu. Osobny katalog najbardziej się przydaje, gdy pomaga utrzymać poprawkę na tyle małą, że jedna osoba może wziąć za nią odpowiedzialność.

Czysty katalog pokazuje, kto za co odpowiada

Opcja worktree daje sprawdzającemu jasny punkt startu bez zatrzymywania pracy drugiego programisty. Może zobaczyć stan wyjściowy i zmianę oraz ponownie uruchomić test. Równie jasno określ zasady współdzielenia połączeń i uprawnienia do wykonania. Dobre przekazanie to mała poprawka, która pokazuje, skąd wyszła, co zmieniła i jakie dowody przemawiają za integracją.

Źródła

• Oficjalny zrzut terminala OpenCode i licencja repozytorium

• Wydanie OpenCode v2.2.6, 6 listopada 2026

• Dokumentacja CLI OpenCode

• Uprawnienia OpenCode V2

• Współdzielenie połączeń MCP w OpenCode

• Podręcznik Git worktree

---

Aby zachować decyzje i eksperymenty związane z pracą w przeszukiwalnym archiwum, załóż konto Telli.sh.