O czym jest ten film
- Tryb zatwierdzania (approval mode) w Claude Code jest bezpieczny, ale zbyt wolny dla długich, złożonych zadań.
- Tryb YOLO (pełna autonomia agenta) jest szybki, ale na realnym projekcie niebezpieczny — zwłaszcza z powodu prompt injection.
- Rozwiązaniem jest sandbox: uruchamianie agenta w izolowanej mikro-maszynie wirtualnej zamiast na własnym komputerze.
- Zmiana jest minimalna — zamiast
claudeuruchamiaszspx run claude, a workflow wygląda identycznie. - Demonstracja różnicy: agent bez sandboxa widzi foldery rodzeństwa i wrażliwe dane, agent w sandboxie — tylko swój projekt.
- Docker Sandboxes dają każdej instancji własne jądro, system plików i sieć (mikro-VM), co odróżnia je od zwykłych kontenerów i dev containerów.
- Instalacja i logowanie są proste; przy pierwszym uruchomieniu wybierasz politykę sieciową: open, balanced lub lockdown.
- Tryb balanced przepuszcza popularne domeny deweloperskie (np. npm), a resztę blokuje; dostęp do konkretnych domen dodaje się osobną komendą.
- Sekrety (np. token GitHub) można bezpiecznie przekazać do sandboxa przez
spx secret, bez przechowywania ich tam w sposób podatny na wyciek. - Praktyczny workflow: agent triażuje 81 zgłoszeń w ~5 minut i tworzy pull request; sandbox jest jednorazowy — właściwym wynikiem jest PR.
Redakcyjne tłumaczenie
Dlaczego tryb zatwierdzania i tryb YOLO nie wystarczają
Wszyscy znamy już te przerażające historie: agenty AI kasujące produkcyjne bazy danych, czyszczące ludziom komputery, a nawet wyciekające dane uwierzytelniające. Właśnie dlatego wiele osób woli uruchamiać Claude Code, Codex czy inne agenty kodujące w trybie zatwierdzania (approval mode). W tym trybie Claude zatrzymuje się i pyta o pozwolenie przed wykonaniem każdej niebezpiecznej komendy.
Problem z tym podejściem jest taki, że jest boleśnie wolne. Agent działa kilka sekund, prosi o zatwierdzenie, klikasz „zatwierdź”, a chwilę później znów pyta o zgodę. Przy złożonych, długotrwałych zadaniach to się po prostu nie sprawdza.
Weźmy jako przykład mój projekt AutoForge. To realny projekt z dużą liczbą użytkowników — ma prawie 2000 gwiazdek na GitHubie, mnóstwo otwartych zgłoszeń (issues) i pull requestów. Gdybym chciał, żeby agent AI przeprowadził triaż tych zgłoszeń, zajęłoby to bardzo długo, gdybym musiał niańczyć cały proces i zatwierdzać każde pojedyncze żądanie.
W tym momencie wiele osób po prostu przełącza agenta w tryb YOLO i pozwala mu przejść przez wszystkie zgłoszenia, wprowadzać zmiany, tworzyć pull requesty i szaleć do woli. Ale w projekcie takim jak ten to nie jest zalecane — i tobie też bym tego nie polecił.
Prompt injection — ukryte zagrożenie
Powód jest następujący. Czy słyszałeś kiedyś o czymś, co nazywa się prompt injection? To sytuacja, w której można nakłonić agenta do wykonania działania, którego użytkownik się nie spodziewał. Może to być subtelny fragment tekstu albo komenda na stronie internetowej, a w projektach open source takie instrukcje mogą być ukryte w zgłoszeniach na GitHubie, a nawet w pull requestach.
Pamiętaj, że w otwartych projektach jak ten każdy przypadkowy użytkownik może utworzyć zgłoszenie, a ja nie mam pojęcia, kim jest ani jakie ma intencje. Łatwo sobie wyobrazić, że agent otwiera dowolne z tych zgłoszeń, przechodzi przez jego treść i w efekcie zostaje nakłoniony do zainstalowania złośliwego pakietu albo wręcz do wycieku danych uwierzytelniających, takich jak klucze SSH z naszego komputera.
Jeśli próbujesz przejść od „vibe codera” do odpowiedzialnego inżyniera pracującego z agentami, naprawdę musisz nauczyć się sandboxów.
(Informacja dodatkowa: „vibe coding” to modny termin na programowanie polegające na luźnym, intuicyjnym poleceniu agentowi AI, co ma zrobić, bez ścisłej kontroli nad kodem).
Sandbox — prosta zmiana, wielka różnica
Sandboxy mogą brzmieć onieśmielająco, ale zabawne jest to, że są śmiesznie proste w użyciu. Jeśli używałeś już Claude Code w terminalu, to naprawdę tylko drobna zmiana. Zamiast uruchamiać claude w trybie „dangerously skip permissions”, komenda zmienia się po prostu na spx run claude.
Wygląda to bardzo znajomo — to Claude Code działający w trybie bypass permissions, czyli tryb YOLO, ale tym razem uruchomiony w środowisku sandbox, we własnej maszynie wirtualnej. To oznacza, że zamiast dostępu do twojego komputera, wszystkich projektów, wszystkich danych uwierzytelniających i wszystkiego, co masz zainstalowane, agent działa teraz we własnej małej maszynie wirtualnej — nazywanej też mikro-VM. Agent działa we własnym środowisku i ma dostęp tylko do plików przypisanych do tego środowiska. Może też instalować pakiety wyłącznie w tym środowisku. A jeśli coś naprawdę pójdzie nie tak, możesz po prostu usunąć to środowisko i niczego nie tracisz. Ryzyko jest całkowicie odizolowane, a co ważniejsze — twój sposób pracy pozostaje dokładnie taki, do jakiego przywykłeś.
Demonstracja: co widzi agent bez sandboxa, a co w sandboxie
Żeby to unaocznić, pokażę krótki przykład. Mam uruchomioną jedną sesję, którą nazwę „claude sandbox”, żeby łatwo ją rozpoznać. Utworzę też drugą sesję Claude Code, działającą w trybie „dangerously skip permissions”. Obie sesje wyglądają i działają identycznie, ale jest między nimi ogromna różnica.
W środowisku bez sandboxa proszę o wykonanie komendy: „Wypisz wszystkie pliki i foldery jeden poziom powyżej bieżącego folderu projektu”. Tę samą instrukcję przekazuję do sandboxa.
W normalnej sesji Claude Code widać, że agent ma dostęp do wszystkich moich projektów. To większy problem, niż mogłoby się wydawać. Zwykle, gdy uruchamiasz Claude Code w nowym folderze projektu, pyta on o pozwolenie na dostęp do tego workspace’u. Ale co, jeśli dasz mu też dostęp do katalogu nadrzędnego, np. do folderu „projects”? Wtedy Claude może wyskoczyć z bieżącego folderu projektu i wejść do dowolnego z folderów rodzeństwa leżących na tym samym poziomie.
Osobiście miałem z tym problemy — tworzyłem nowy folder na projekt, prosiłem Claude’a o zmiany i widziałem, jak opuszcza bieżący folder, wchodzi do jednego z innych projektów, czyta jego system projektowy albo architekturę i czerpie z niego inspirację. A tego nie chcę — każdy projekt jest wyjątkowy. Zdarzało mi się to z flagowymi modelami: z Fable i z Opus 4.8. To naprawdę frustrujące.
W środowisku sandbox jest inaczej. Agent mówi, że ma dostęp do folderu projektów, ale nie ma w nim nic więcej — to jedyny projekt w tym folderze. Ma dostęp wyłącznie do AutoForge i niczego innego.
Można też uruchomić wiele różnych komend, żeby wydobyć klucze API, sekrety czy dane uwierzytelniające SSH. To naprawdę przerażające, do czego te agenty mają dostęp. Ale w środowisku sandbox mamy spokój ducha, że agent nie może dobrać się do żadnych innych plików, folderów ani wrażliwych informacji na tym komputerze.
W tym filmie pokażę, jak skonfigurować Docker Sandboxes, żeby uruchamiać Claude Code w trybie YOLO w odpowiedzialny sposób. Pokażę też bardziej złożony workflow deweloperski, w którym uruchomimy Claude Code w tej maszynie wirtualnej, połączymy go z GitHubem i zbudujemy proces, w którym agent triażuje wszystkie otwarte zgłoszenia, wprowadza zmiany, a nawet tworzy pull requesty do przejrzenia.
Kontener a Docker Sandbox — różnica w klasie izolacji
Chcę zaznaczyć, że jest różnica między kontenerem a Docker Sandboxem. W Docker Sandboxes każdy sandbox ma własną maszynę wirtualną, czyli mikro-VM, a każda z tych instancji ma własne jądro, własny system plików i własną sieć. Jest to wspierane przez wszystkie systemy operacyjne — dla każdego z nich istnieje już rodzaj hypervisora, który potrafi uruchamiać te małe maszyny.
Ludzie pytali mnie wcześniej: czy to nie to samo co dev container? Nie. W Docker Sandboxes instancja ma własne jądro, więc to zupełnie inna klasa izolacji. Jeśli to zabrzmiało zbyt technicznie — nie stresuj się, w praktyce jest to bardzo proste.
Muszę wspomnieć, że ten film jest sponsorowany przez Dockera. Ale Docker istnieje od bardzo dawna, a jeśli oglądałeś moje filmy, wiesz, że cały czas korzystam z Dockera i Docker Desktop. Docker Sandboxes są wreszcie na tyle stabilne, że można ich używać — i cieszę się, że zacznę je wykorzystywać we własnych projektach.
Instalacja i logowanie
Instalacja jest bardzo prosta. Wystarczy skopiować jedną z komend. Ponieważ korzystam z Windowsa, kopiuję komendę dla Windowsa, otwieram PowerShell i ją uruchamiam. To pobierze i zainstaluje Docker Sandboxes. Potem wystarczy uruchomić komendę spx i się zalogować — pojawi się prośba o potwierdzenie kodu. I to wszystko — gotowe. Możemy zamknąć PowerShella.
Pierwsze uruchomienie i polityki sieciowe
Korzystanie z Docker Sandbox jest bardzo podobne do tego, co już znasz. Otwierasz terminal w folderze projektu i zamiast claude uruchamiasz spx run claude. Jeśli używasz Codeksa, możesz zamienić to na codex, a nawet na coś w rodzaju Copilota — wspierają kilka agentów kodujących, ale w tym filmie przyjrzymy się Claude’owi.
Przy pierwszym uruchomieniu tworzona jest nowa maszyna wirtualna. Konfiguracja zajmuje kilka minut, a potem pojawi się pytanie o globalną politykę sieciową. Masz trzy opcje:
- Open — dostępny jest cały ruch sieciowy, agent może wejść na dowolną stronę.
- Lockdown — agent nie może wejść na żadną stronę; musisz nadawać bardzo konkretne uprawnienia, do których domen czy witryn ma dostęp.
- Balanced — dostępne są wszystkie popularne domeny deweloperskie, np. npm. Agent może pobierać i instalować biblioteki z bezpiecznych źródeł, ale nie wejdzie np. na Amazon.
Wybierzmy tryb balanced. Jesteśmy w Claude Code. Jeśli to twoje pierwsze uruchomienie Claude Code w tej maszynie wirtualnej, musisz wykonać komendę /login i przejść przez uwierzytelnianie subskrypcją lub kluczami API.
(Informacja dodatkowa: w transkrypcie automatycznym komenda logowania zapisana jest jako /lo — chodzi o /login).
Napiszę „hej”, żeby sprawdzić, czy wszystko działa. Teraz Claude Code działa we własnej maszynie wirtualnej i można go bezpiecznie uruchamiać w trybie YOLO.
Nadawanie dostępu do konkretnych domen
Jak dopuścić dostęp do bardzo konkretnych domen? Proszę agenta: „Wejdź na anthropic.com i pobierz najnowsze wiadomości”. Pojawiają się komunikaty „forbidden”, a agent mówi, że nie mógł wejść na tę domenę z powodu polityki sandboxa. Żeby odblokować bezpośrednie pobieranie w przyszłości, można uruchomić podpowiadaną komendę. Kopiuję ją, wklejam w nowej sesji i to dodaje nowe reguły. Proszę agenta, żeby spróbował ponownie — tym razem udało mu się wejść na stronę Anthropic.
To pokazuje, jak restrykcyjny jest tryb balanced. Jeśli chcesz nadać agentowi bardzo konkretny dostęp, po prostu uruchom tę komendę, a od tej pory agent będzie miał dostęp do wskazanych domen.
Zanim przejdziemy dalej — jeszcze jedno o uprawnieniach. Jeśli zorientujesz się, że popełniłeś błąd i polityka jest dla ciebie zbyt restrykcyjna, możesz uruchomić komendę spx policy reset, potwierdzić i wrócić do kreatora. Możesz wtedy odejść od balanced na rzecz open albo lockdown — jak wolisz. Na potrzeby demonstracji zostaję przy balanced.
Bezpieczne przekazywanie sekretów i połączenie z GitHubem
W tym workflow połączę instancję Claude Code z moim repozytorium GitHub. Przy okazji pokażę, jak bezpiecznie przechowywać sekrety w środowisku sandbox, żeby agent w ogóle nie mógł ich wyciec.
Najpierw musisz uwierzytelnić konto GitHub w GitHub CLI. Robisz to na głównym komputerze, a nie w sandboxie. Powinieneś mieć zainstalowane CLI — jeśli nie masz pewności, uruchom gh auth login. Jeśli wyskoczy błąd, to znaczy, że jeszcze tego nie skonfigurowałeś; wtedy zainstaluj GitHub CLI i uwierzytelnij konto. Ja już to zrobiłem, więc wychodzę.
Ten krok zapisuje gdzieś na komputerze nasze połączenie z GitHubem — klucz API czy sekret. Nigdy nie chcemy, żeby agent przypadkiem wyciekł tę informację. Jedną z opcji byłoby uruchomienie sandboxa i poproszenie Claude’a, żeby sam skonfigurował CLI i uwierzytelnił konto — ale wtedy sekret jest przechowywany w środowisku sandbox i Claude mógłby go wyciec przy prompt injection.
Zamiast tego przechowamy sekret w bardzo bezpieczny sposób. To naprawdę proste: uruchamiamy gh auth token i przekierowujemy (pipe) wynik do spx secret, ustawiając nowy sekret globalny o nazwie „github”. To po prostu bierze token GitHub z głównego komputera i przekazuje go do sekretów w sandboxie. Naciskam enter — sekret zapisany. To zresztą rekomendowany przez Docker Sandboxes sposób bezpiecznego kopiowania takich tokenów.
Następnie uruchamiam spx run claude i potwierdzam, że sekret został ustawiony, komendą spx secret ls. Widać, że sandbox ma na tym etapie dostęp tylko do dwóch zmiennych globalnych: github oraz anthropic (bo używamy Claude Code).
Odtwarzanie sandboxa po dodaniu sekretów
Rzecz w tym, że gdy dodajesz nowe sekrety lub zmienne środowiskowe, nie stają się one automatycznie dostępne w sandboxie. Musisz odtworzyć sandbox, żeby zmienne stały się dostępne.
Jak usunąć lub odtworzyć środowisko? Wpisujesz spx ls, co wypisze wszystkie dostępne sandboxy — i tak, możesz mieć uruchomiony więcej niż jeden na komputerze i w projekcie. Ja mam tylko jeden, więc kopiuję jego nazwę, uruchamiam spx rm z nazwą sandboxa i usuwam go. Potem odtwarzam sandbox komendą spx run claude. Sprawdzam, czy wszystko zadziałało, prosząc Claude’a o wykonanie gh auth status — jeśli poprawnie ustawiłeś zmienną środowiskową, powinno pokazać, że jesteś zalogowany do GitHuba.
Praktyczny workflow: triaż zgłoszeń, poprawki i pull requesty
Daję agentowi ciekawe zadanie. Lubię robić trzy rzeczy. Po pierwsze, proszę agenta o triaż wszystkich otwartych zgłoszeń. Po drugie, o osobny workflow, w którym agent zajmuje się „szybkimi wygranymi” (quick wins), wprowadza faktyczne zmiany i tworzy dla nich pull request. Po trzecie, mam zwykle trzeciego agenta, który przechodzi przez wszystkie pull requesty i je recenzuje.
Wysyłam prompt: „Połącz się z repozytorium GitHub AutoForge i przeprowadź triaż otwartych zgłoszeń. Użyj workflow z wieloma agentami przechodzącymi przez każde zgłoszenie. Na koniec utwórz plik HTML i posortuj zgłoszenia według priorytetu oraz dodaj TL;DR dla każdego”.
Szczerze mówiąc, nie sprawdziłem nawet, jakiego modelu używam — zrobię to najpierw. Model jest ustawiony na 4.6, którego zdecydowanie nie chcę używać. Przełączam na Fable, a poziom wysiłku (effort) ustawiam na wysoki. Wznawiam i wysyłam.
Claude utworzył workflow. Można wejść w niego, żeby zobaczyć, co robi — uruchamia całkiem sporo różnych agentów, w partiach (batchach). Mogę klikać w prawo, żeby przechodzić między partiami, i wejść do wybranej, żeby zobaczyć, czym zajmują się agenci. Właśnie ukończył krok normalizacji. Wracam do widoku głównego — główny workflow jest gotowy. Główny agent skonsoliduje teraz wszystkie wyniki i utworzy dla nas plik issues.html.
To było zaskakująco szybkie. Cały proces triażu zajął chyba jakieś 5 minut na przejście przez 81 zgłoszeń. To naprawdę duża sprawa. Workflowy mają swoją złą sławę, nie będę ukrywał — potrafią niepotrzebnie szybko spalać kredyty. Ale przy wyzwaniach takich jak to, które wymagają czytania wielu różnych obiektów czy zgłoszeń równolegle, workflowy potrafią być niesamowicie przydatne.
Claude utworzył plik issues.html, który uruchamiam w Live Server. Daje mi to bardzo przejrzysty widok wszystkich zgłoszeń, posortowanych według priorytetu. Mamy jedno zgłoszenie krytyczne do zajęcia się, mamy pozycje o wysokim priorytecie. Z perspektywy użytkownika, wizualnie, jest to niezwykle użyteczne.
Najpiękniejsze jest to, że mogę po prostu kontynuować pracę. Utworzyłem nową sesję i wciągnąłem zgłoszenia. Poprosiłem agenta, żeby rozwiązał pięć zgłoszeń o najwyższym priorytecie i utworzył pull request, używając workflow. Claude odpalił workflow i bada teraz pięć najważniejszych zgłoszeń — za moment zacznie implementację, zweryfikuje zmiany i na końcu utworzy pull requesty.
Efekt: Claude’owi zajęło to około 40 minut. Workflow był całkiem zajęty — zbadał zgłoszenia, zaimplementował pięć zmian, wykonał krok weryfikacji i recenzji, a na końcu dał nam ten pull request w repozytorium GitHub. Wszystko, co muszę zrobić, to przeczytać go, i jeśli jestem zadowolony z wyników, scalić (merge) pull request z powrotem do gałęzi głównej. Wszystko się zgadza, nawet wszystkie testy (checks) przeszły.
Sandbox jest jednorazowy — wynikiem jest pull request
Na koniec myśl dla ciebie. W tym workflow to pull request był właściwym wynikiem. Sandbox jest jednorazowy. Jeśli uznam, że to środowisko zawiera cokolwiek, czego nie chcę, wystarczy, że wyjdę z Claude Code, uruchomię spx ls, chwycę nazwę sandboxa i uruchomię spx rm z tą nazwą. I już go nie ma — jest całkowicie jednorazowy.
Jeszcze raz dziękuję Dockerowi za sponsorowanie tego filmu. Sandboxy możesz wypróbować za darmo — link zostawię w opisie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Sandbox rozwiązuje dylemat „bezpieczeństwo albo szybkość”
Na czym polega: Tryb zatwierdzania jest bezpieczny, ale wolny; tryb YOLO jest szybki, ale ryzykowny. Sandbox pozwala uruchomić agenta z pełną autonomią, izolując jednocześnie ryzyko.
Jak stosować: Do długich, wieloetapowych zadań (triaż zgłoszeń, masowe poprawki) uruchamiaj agenta w sandboxie w trybie bypass permissions, zamiast klikać „zatwierdź” przy każdej komendzie.
Na co uważać: Sandbox nie zwalnia z przeglądania wyników. Właściwym wynikiem jest pull request, który i tak trzeba przeczytać przed scaleniem.
2.Prompt injection to realne zagrożenie w projektach open source
Na czym polega: Złośliwe instrukcje mogą być ukryte w treści zgłoszeń i pull requestów tworzonych przez nieznanych użytkowników; agent czytający tę treść może zostać nakłoniony do instalacji złośliwego pakietu lub wycieku kluczy SSH.
Jak stosować: Każde zadanie, w którym agent czyta treści od stron trzecich (issues, strony WWW, PR-y), traktuj jako niezaufane i uruchamiaj wyłącznie w izolowanym środowisku.
Na co uważać: Zagrożenie nie zależy od modelu — dotyczy też flagowych modeli. Nie zakładaj, że „mądry” model sam rozpozna manipulację.
3.Przejście na sandbox to zmiana jednej komendy
Na czym polega: Zamiast claude uruchamiasz spx run claude. Cały workflow wygląda i działa identycznie jak zwykły Claude Code.
Jak stosować: Wypróbuj sandbox na istniejącym projekcie — bariera wejścia jest minimalna, nie musisz przebudowywać sposobu pracy.
Na co uważać: Pierwsze uruchomienie tworzy maszynę wirtualną i trwa kilka minut; nie myl tego z awarią.
4.Docker Sandbox to mikro-VM, nie zwykły kontener
Na czym polega: Każdy sandbox ma własne jądro, system plików i sieć — to inna, mocniejsza klasa izolacji niż kontener czy dev container.
Jak stosować: Gdy potrzebujesz twardej separacji od komputera hosta (dane uwierzytelniające, inne projekty), wybieraj mikro-VM, a nie zwykły kontener.
Na co uważać: Silniejsza izolacja oznacza narzut — pierwsze utworzenie środowiska trwa dłużej, a każdą maszynę trzeba świadomie zarządzać i usuwać.
5.Izolacja zapobiega „wychodzeniu” agenta poza folder projektu
Na czym polega: Bez sandboxa agent z dostępem do katalogu nadrzędnego może zaglądać do sąsiednich projektów i czerpać z nich architekturę czy design. W sandboxie widzi wyłącznie swój projekt.
Jak stosować: Jeśli zależy ci, by agent nie mieszał kontekstów między projektami, izoluj każdy projekt w osobnym sandboxie.
Na co uważać: Nawet lokalnie, bez złych intencji, agent potrafi „uciec” do folderów rodzeństwa — problem dotyczy też flagowych modeli, więc sama ostrożność w promptach nie wystarcza.
6.Wybieraj politykę sieciową świadomie: open, balanced, lockdown
Na czym polega: Przy pierwszym uruchomieniu ustawiasz globalną politykę sieci. Balanced przepuszcza popularne domeny deweloperskie (np. npm) i blokuje resztę.
Jak stosować: Zacznij od balanced jako rozsądnego domyślnego kompromisu; dla zadań szczególnie wrażliwych rozważ lockdown i jawne dopuszczanie domen.
Na co uważać: Balanced jest restrykcyjny — nawet anthropic.com bywa zablokowany. Politykę zmienisz komendą spx policy reset, wracając do kreatora.
7.Konkretne domeny dopuszczaj jawnie zamiast otwierać całą sieć
Na czym polega: Gdy agent trafia na komunikat „forbidden”, sandbox podpowiada komendę odblokowującą dostęp do danej domeny na przyszłość.
Jak stosować: Dodawaj dostęp punktowo — tylko te domeny, których zadanie faktycznie potrzebuje — zamiast przełączać całość w tryb open.
Na co uważać: Otwieranie coraz szerszego dostępu stopniowo eroduje sens sandboxa; utrzymuj listę dozwolonych domen minimalną.
8.Sekrety przekazuj do sandboxa bezpieczną ścieżką, nie każ agentowi się logować
Na czym polega: Zamiast prosić agenta o skonfigurowanie i uwierzytelnienie CLI (co zapisałoby sekret w podatny sposób), przekazujesz token z hosta przez pipe do spx secret jako sekret globalny.
Jak stosować: Uwierzytelnij się na głównym komputerze (np. gh auth login), a następnie gh auth token | spx secret .... Sprawdź stan przez spx secret ls.
Na co uważać: Jeśli agent sam trzyma sekret w środowisku, prompt injection może doprowadzić do jego wycieku. Ogranicz zestaw zmiennych globalnych do niezbędnego minimum.
9.Po dodaniu sekretów trzeba odtworzyć sandbox
Na czym polega: Nowe zmienne środowiskowe nie stają się dostępne automatycznie — trzeba usunąć i utworzyć sandbox od nowa (spx ls → > → spx run claude).
Jak stosować: Po każdej zmianie sekretów odtwórz środowisko i zweryfikuj, np. prosząc agenta o gh auth status.
Na co uważać: Pominięcie tego kroku daje mylące błędy „braku dostępu”, choć sekret jest poprawnie zapisany — problem tkwi w nieodświeżonym środowisku.
10.Workflowy z wieloma agentami: potężne, ale kosztowne
Na czym polega: Równoległe agenty przetriażowały 81 zgłoszeń w ~5 minut, a osobny workflow rozwiązał pięć zgłoszeń i utworzył pull request w ~40 minut (z krokiem weryfikacji i recenzji).
Jak stosować: Sięgaj po workflowy tam, gdzie trzeba równolegle przeczytać wiele obiektów (zgłoszenia, PR-y). Sprawdź model i poziom wysiłku przed startem — w materiale świadomie wybrano Fable z wysokim effortem.
Na co uważać: Workflowy potrafią szybko spalać kredyty. Zawsze weryfikuj ustawiony model przed wysłaniem zadania (domyślne 4.6 nie musi być tym, czego chcesz) i przeglądaj wynikowy pull request przed scaleniem.