O czym jest ten film
- Tryb „yolo” (u Claude Code:
--dangerously-skip-permissions) pozwala agentowi wykonywać dowolne polecenia bez pytania o zgodę — jest wygodny, ale ryzykowny. - Agent uruchomiony bezpośrednio na komputerze ma dostęp do całego systemu plików, procesów, zmiennych środowiskowych i sieci.
- Realne „horror stories”: skasowanie katalogu domowego przez
rm -rf, wyczyszczenie bazy produkcyjnej, porzucenie git stash z niezacommitowaną pracą. - Zabezpieczenia w promptach są zawodne — model po dłuższej rozmowie „głupieje” i zapomina o ograniczeniach (context rot).
- Rozwiązaniem nie jest rezygnacja z trybu yolo, lecz uruchamianie agenta w izolowanym sandboksie.
- Autor pokazuje Docker Sandboxes jako darmowe, proste w instalacji i działające z Claude Code „od ręki” narzędzie.
- Sandbox daje izolację systemu plików i procesów, własny silnik Dockera oraz izolację sieciową z listą dozwolonych adresów.
- Lista dozwolonych URL chroni przed atakami typu prompt injection, które mogłyby wykraść klucze API.
- Uruchomienie to jedno polecenie
>; opcja--clonedaje pełną kopię repozytorium i całkowitą izolację. - Cztery warstwy izolacji: hipernadzorca (procesy/pliki), sieć, silnik Docker, przestrzeń robocza.
Redakcyjne tłumaczenie
Czym jest tryb „yolo” i dlaczego go używamy
Tryb pomijania uprawnień w Claude Code — --dangerously-skip-permissions, potocznie „yolo mode” — sprawia, że agent kodujący może uruchomić na twoim komputerze dowolne polecenie, ani razu nie pytając o zgodę. Każdy agent kodujący ma jakąś wersję tego trybu i prawdopodobnie z niej korzystasz, może nawet codziennie, tak jak ja. To czyni agenta bardzo sprawnym, ale niesie ze sobą poważne zagrożenia. Nie można pozwolić agentowi swobodnie hulać po komputerze bez realnych zabezpieczeń.
Zapewne słyszałeś te opowieści grozy o Claude Code, Cursorze czy Codeksie, które wyczyściły całe bazy danych albo skasowały katalogi. Prawdopodobieństwo jest niskie, bo agenty są inteligentne, i możesz myśleć, że tobie się to nigdy nie przydarzy — aż się przydarzy. Wystarczy, że stanie się to raz, żeby konsekwencje były drastyczne.
Chcę więc omówić wszystkie zagrożenia — bo nawet jeśli sądzisz, że je znasz, pewnie nie znasz wszystkich. Potem przejdziemy do głównego rozwiązania, czyli sandboksowania. Pokażę, jak to działa, na przykładzie sandboksów Docker — są darmowe, bardzo łatwe w konfiguracji i naprawdę wydajne.
Idea sandboksu jest prosta: to odizolowane środowisko, w którym pracuje agent. Możemy dać mu pełną autonomię bez ryzyka wynikającego z uruchamiania go bezpośrednio na naszej maszynie. Rozwiązaniem zdecydowanie nie jest rezygnacja z trybu yolo. Nie chcesz siedzieć i zatwierdzać każdej pojedynczej akcji agenta — będą ich setki. To strata czasu, a agent przestaje być autonomiczny. Dlatego chcemy trybu yolo, tylko wykonanego bezpiecznie. Dziś, dzięki narzędziom takim jak sandboksy Docker, wcale nie jest to trudne.
Zagrożenia: pełny dostęp do systemu
(Informacja dodatkowa: autor przygotowywał ten materiał we współpracy z Dockerem i korzysta z ich dokumentacji, by pokazać poszczególne poziomy izolacji.)
Najbardziej oczywiste zagrożenie przy uruchamianiu agenta bezpośrednio na komputerze to dostęp do całego systemu plików. Są pewne zastrzeżenia związane z uprawnieniami skonfigurowanymi w systemie, ale w praktyce trzeba przyjąć, że jeśli agent nie działa w izolowanym środowisku, to każdy plik i folder na komputerze jest w jego zasięgu — może go odczytać, zmodyfikować, a nawet usunąć.
To samo dotyczy całego środowiska i wszystkich uruchomionych aplikacji. Agent może zabijać procesy, edytować zmienne środowiskowe — może zrobić wszystko. Często agenty gubią się przy konfliktach portów i zabijają aplikacje, próbując doprowadzić bieżącą sesję do działania. To duże ryzyko. Potrzebujemy izolacji, w której mamy własny zestaw procesów, a nawet własny silnik Dockera zarządzający wyłącznie swoimi kontenerami — nie niszczący kontenerów innych rzeczy, które mamy uruchomione.
Ważna jest też izolacja sieciowa, dzięki której pozwalamy na ruch tylko do wybranych witryn. To istotne, bo jeśli twojego agenta dosięgnie atak typu prompt injection, może on przechwycić klucz API i wysłać go pod adres, gdzie czeka na te informacje atakujący. Dlatego lista dozwolonych adresów, do których agent może sięgać podczas researchu czy testowania API, jest niezwykle ważna.
(Informacja dodatkowa: prompt injection to atak polegający na wstrzyknięciu złośliwych instrukcji w treść, którą agent przetwarza — np. w plik, dokumentację czy odpowiedź serwisu — tak, by wykonał je jak polecenie użytkownika.)
Co potrafi pójść nie tak — przykłady
Zróbmy kilka przykładów tego, co może się zepsuć, gdy agent działa w trybie yolo bezpośrednio na komputerze. Są to scenariusze spreparowane na potrzeby tej rozmowy, ale pokażę też realne przypadki.
Pierwszy: wprost proszę agenta, żeby usunął node_modules i plik lock oraz przeinstalował wszystkie zależności. To będzie wolne, kosztowne w tokenach i ma negatywne konsekwencje. Tak, tu proszę o to wprost, ale agenty robią to czasem same — kiedy jesteś głęboko w żmudnym debugowaniu, model wyczerpuje inne opcje i stwierdza: „Dobra, po prostu przeinstaluję zależności, pewnie jest tu jakiś problem z zależnościami”. Widziałem, jak sam to robi. Co ciekawe, w tej rozmowie widać wspomnianą inteligencję — agent najpierw protestuje, rozumie, że to ryzykowna operacja. Ale straszne jest to, że wystarczy jeden follow-up: „Nie, po prostu kontynuuj”, i natychmiast przełącza się w tryb czyszczenia wszystkiego. To zdumiewające, jak łatwo przechodzi od „nie, to zbyt ryzykowne” do „dobra, zróbmy to”.
Drugi problem, który zdarza się zbyt często: agent czyta klucze prywatne lub zmienne środowiskowe, nawet jeśli wcześniej w rozmowie prosiłeś, by tego nie robił — bo uznaje, że do debugowania musi ten klucz przeczytać. W moim przykładzie od razu, bez protestu, odczytał plik. A najgorsze, że sięgnął do folderu ~/.ssh — nie do klucza w bazie kodu, lecz do folderu zupełnie odrębnego od bieżącego środowiska pracy. Do klucza, którego nigdy nie chciałbym pokazywać agentowi. Widziałem takie zachowanie, gdy agent debugował połączenie SSH.
Trzeci klasyk: agent grzebiący w bazie danych. Masz błąd w kodzie, agent nie potrafi go znaleźć i zakłada, że skoro kod korzysta z bazy, to coś jest nie tak ze schematem. Wycofuje migrację, tworzy nową i potrafi kompletnie rozwalić bazę oraz aplikację. Tu, jak wcześniej, najpierw protestuje — ale po jednym dodatkowym poleceniu wykonuje całość. Doceniam, że zrobił kopię zapasową bazy. Rozumie ryzyko, protestuje, robi backup — to dobrze. Ale nie mamy gwarancji, że agent zawsze podejmie te środki ostrożności.
Dlaczego zabezpieczenia w promptach zawodzą
To jest sedno: widzimy przebłyski inteligencji, ale zwłaszcza w dłuższych rozmowach agenty tę inteligencję tracą i robią naprawdę głupie, szkodliwe rzeczy. Jeśli kiedykolwiek agent zrobił ci coś naprawdę złego, prawdopodobnie było to pod koniec okna kontekstowego modelu, bo każdy duży model językowy ma swoją „strefę głupoty”.
(Informacja dodatkowa: „context rot” to degradacja jakości odpowiedzi modelu wraz ze wzrostem długości kontekstu — im więcej tokenów, tym łatwiej model gubi wcześniejsze instrukcje.)
Pierwsze kilkaset tysięcy tokenów model działa na szczycie możliwości, ale przy dłuższej rozmowie — szczególnie w długich sesjach diagnostycznych — przekraczasz te rdzeniowe 200–300 tysięcy tokenów i wchodzisz w resztę okna, gdzie model zaczyna być przeciążony i podejmuje głupie decyzje. Zapomina instrukcje z początku rozmowy, łącznie z promptem systemowym. Wszystkie zabezpieczenia, które wpisałeś w prompt — czego ma nie robić, jakie ryzyka ma pamiętać — ulatniają się. Wtedy potrafi wyczyścić bazę bez backupu, skasować foldery i tym podobne.
Dlatego nie możemy polegać na zabezpieczeniach w promptach. To, że agent zazwyczaj wydaje się rozumieć, co wolno, a czego nie, nie znaczy, że zawsze się do tego zastosuje. Właśnie dlatego chcemy egzekwować ochronę sandboksem, a nie prosić agenta, żeby ją wdrażał albo o niej pamiętał.
Prawdziwe przypadki z GitHuba
Obiecałem realne przykłady — wystarczy zajrzeć na listę zgłoszeń w repozytorium Claude Code na GitHubie, bo ludzie uwielbiają dzielić się tym, jak Claude Code ich pogrążył. Jedna osoba: Claude Code wykonał osławione rm -rf, kasując cały katalog domowy. Nigdy nie chcesz, by agent uruchomił to polecenie. r to „recursive” — usuń każdy folder i wszystko w środku, a f to „force”. Wyczyściło im wszystko. A miesiąc później to samo spotkało kolejną osobę.
To było prawie rok temu. Agenty rzadziej robią dziś takie rzeczy, ale to wciąż możliwe. To zgłoszenie zamknięto jako „not planned”, bo problem nie leży w samym Claude Code — po prostu czasem modele językowe uznają, że muszą to zrobić. Gdy sięgają po ostatnią deskę ratunku, jesteś daleko w rozmowie, z tym context rot — wtedy zdarzają się takie rzeczy: wykonanie destrukcyjnego polecenia na bazie, wyczyszczenie bazy produkcyjnej. Mój drogi — nie powinieneś był w ogóle dać Claude Code możliwości łączenia się z bazą produkcyjną. Ale kto wie, może sam ją znalazł, zaglądając w konfigurację gdzieś na komputerze. Właśnie dlatego potrzebujesz izolacji sandboksu.
Inny częsty przypadek: porzucenie całego git stash — masy niezacommitowanej pracy. Agenty potrafią się pogubić przy różnych gałęziach Gita czy konfliktach scalania i robią coś takiego. To wszystko pokazuje, dlaczego potrzebujemy izolacji. Agent nie powinien móc sięgnąć do bazy produkcyjnej ani niczego edytować czy kasować w katalogu domowym.
Docker Sandboxes — jak to działa
Świadomie czekałem z tym materiałem do teraz, bo sandboksy Docker to w moim odczuciu pierwsze rozwiązanie, które naprawdę uczyniło sandboksy dostępnymi. Instalacja to jedno polecenie, konfiguracja jest prosta, a całość działa z agentami takimi jak Claude Code od ręki. Możesz też po prostu podać temu narzędziu link do dokumentacji i pozwolić agentowi zainstalować wszystko za ciebie — tak właśnie zrobiłem. To darmowe i działa lokalnie na twojej maszynie, tak jak Docker Desktop i twoje kontenery. Dockera używam od ośmiu lat, jeszcze zanim zająłem się AI.
Po uruchomieniu polecenia instalacyjnego (dla Maca lub Windowsa) start z agentem to jedna komenda: sbx (skrót od „sandbox”), run i nazwa agenta — np. claude. Wszystko wygląda normalnie, to zwykły terminal Claude Code, ale pod spodem działa w odizolowanej maszynie wirtualnej sandboksu.
Przykład: mogę zrobić !ls, żeby zobaczyć bieżący katalog — nasza baza kodu jest zamontowana w VM. Ale gdy zrobię !ls na folderze .ssh z wcześniejszego demo, dostaję „not found”. Nie mamy dostępu do reszty maszyny. Mamy prawdziwą izolację, a jednocześnie nad tą bazą kodu pracujemy dokładnie jak zwykle — niczego nie tracimy, będąc w sandboksie, a jesteśmy w pełni chronieni.
W sandboksie mogę instalować zależności, uruchomić serwer deweloperski, zbudować projekt w obraz Dockera za pomocą odizolowanego silnika Dockera. Cała praca toczy się normalnie — muszę tylko czasem ustawić politykę wyjścia z kontenera, gdy jest potrzebne. W kolejnej rozmowie widać, że agent nie może odczytać folderu .ssh — tu jesteśmy chronieni. W innej próbuje sięgnąć do adresu spoza listy dozwolonych i dostaje 403 — ale nie od serwera; żądanie nigdy nie opuściło kontenera, bo zablokował je proxy sandboksu. Mamy konfigurację definiującą, do których witryn wolno się łączyć, więc nie musimy się martwić o wyciek żądań przy ewentualnym prompt injection.
Politykę dla poszczególnych witryn można ustawiać: sprawdzam, czy z VM da się dosięgnąć danej strony, dodaję ją do listy dozwolonych i od tej pory każdy nowy sandboks ma do niej dostęp. Jeśli operowanie na konkretnych komendach wydaje się onieśmielające — bez obaw. Możesz podać dokumentację sandboksów Docker swojemu agentowi i pozwolić mu to skonfigurować z twoją pomocą, łącznie z uruchomieniem sandboksu i testami. Ja przy tworzeniu tego materiału zleciłem całą konfigurację Claude Code.
Weryfikacja izolacji
W ostatniej rozmowie dosłownie powiedziałem agentowi: „Zanim powierzę sandboksowi prawdziwą pracę, chcę zweryfikować, że izolacja jest ustawiona poprawnie. Uruchom te testy: czy widzisz którykolwiek z moich plików hosta, choćbyś bardzo się starał? Czy dosięgniesz usługi na maszynie hosta — czy nie mamy izolacji procesów? Czy dotkniesz socketu Dockera hosta? Czy pogrzebiesz w moich kontenerach?”. Agent przeszedł przez wszystko, uruchomił mnóstwo poleceń, a na końcu: pliki hosta poza przestrzenią roboczą — niewidoczne; usługi hosta — nieosiągalne; socket Dockera — to zagnieżdżony demon, nie nasz host, bo mamy odrębny silnik Dockera. Wszystko całkowicie odizolowane, a mimo to mamy pełne środowisko do realnej pracy.
Wracając do polecenia >: montuje ono bieżący katalog do sesji w VM. Edytujemy pliki bezpośrednio na maszynie hosta, ale mamy dostęp tylko do nich. Jeśli chcesz pełnej izolacji, dodaj --clone — powstanie kopia bazy kodu i to ją wnosimy do sandboksu. Dzięki temu nie ruszamy historii Gita i nie musimy się martwić o złośliwe polecenia Gita. Niezależnie od poziomu izolacji i kontroli, jaki chcesz uzyskać, sandboksy Docker to umożliwiają.
Cztery warstwy izolacji
Na koniec przejdźmy przez warstwy izolacji sandboksu (tu: Docker Sandboxes, ale znajdziesz to wszędzie — Docker robi to najlepiej).
Izolacja hipernadzorcy daje izolację procesów i systemu plików, więc nie zamkniemy przypadkiem procesów ani nie skasujemy plików na hoście. Do tego pełne sprzątanie: po usunięciu sandboksu przez sbx rm maszyna wirtualna i cała jej zawartość są kasowane, więc nie zajmują miejsca. Wewnątrz VM agent działa jako użytkownik z uprawnieniami sudo — może robić wszystko, bo nie obchodzi nas, co wyprawia w środku. Na tym polega izolacja.
Izolacja sieciowa — to pokazana wcześniej możliwość ograniczenia żądań do wybranych witryn i zarządzania listą dozwolonych.
Izolacja silnika Dockera — prawdopodobnie unikalna dla Dockera. Mamy osobny silnik i osobny zestaw kontenerów przy budowaniu i testowaniu aplikacji w sandboksie. Uwielbiam to, bo mój Docker Desktop na hoście z czasem bardzo się „zapycha” od kolejnych kontenerów testowych. Odizolowane środowisko per aplikacja jest świetne, a główny Docker Desktop na hoście zostaje zarezerwowany dla aplikacji, których faktycznie używam.
Izolacja przestrzeni roboczej — bezpośredni montaż (edycja plików danej bazy kodu lokalnie w VM) albo tryb clone z pełną kopią, dzięki czemu nie ruszamy niczego na własnym komputerze.
Podsumowanie
Tym samym omówiliśmy wszystkie zagrożenia trybu yolo i sposób ich rozwiązania sandboksem. Wdrożenie tych zabezpieczeń jest kluczowe ze względu na ataki prompt injection oraz agenty czyszczące bazy, pliki i stan Gita. Tak wiele może pójść nie tak, zwłaszcza gdy agenty wpadają w długie sesje debugowania i coraz mocniej halucynują. Trzeba się chronić sandboksem. Zachęcam: wypróbuj dziś sandboksy Docker — łatwo je zainstalować i za darmo zacząć.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Tryb „yolo” jest wygodny, ale to realne ryzyko, nie hipotetyczne
Na czym polega: Uruchamianie agenta z pominięciem uprawnień (--dangerously-skip-permissions) daje mu prawo do dowolnych poleceń na twoim komputerze. Prawdopodobieństwo katastrofy jest niskie, ale niezerowe — a wystarczy jeden raz.
Jak stosować: Traktuj tryb yolo jako standard pracy dla wydajności, ale nigdy nie uruchamiaj go „na goło” na maszynie hosta bez warstwy izolacji.
Na co uważać: Nie łudź się, że „mnie się nie zdarzy”. Najgroźniejsze błędy pojawiają się właśnie u doświadczonych użytkowników, którzy przyzwyczaili się do bezproblemowego działania agenta.
2.Zabezpieczenia w promptach są zawodne — izolacja musi być egzekwowana zewnętrznie
Na czym polega: Agent potrafi zrozumieć ryzyko i zaprotestować, ale po jednym dodatkowym poleceniu wykonuje destrukcyjną akcję. W dłuższych rozmowach zapomina nawet prompt systemowy.
Jak stosować: Nie polegaj na instrukcjach typu „nie kasuj bazy” w pliku reguł. Wymuszaj ograniczenia na poziomie środowiska (sandboks, uprawnienia systemowe), a nie języka.
Na co uważać: To, że agent „rozumie” zasady dziś, nie znaczy, że zastosuje je za 200 tysięcy tokenów. Reguły w promptach to sugestia, nie gwarancja.
3.„Context rot” to moment największego zagrożenia
Na czym polega: Po przekroczeniu ok. 200–300 tys. tokenów jakość decyzji modelu spada — zapomina wcześniejsze instrukcje i sięga po drastyczne rozwiązania „ostatniej szansy”.
Jak stosować: W długich sesjach debugowania rób świadome resety — zaczynaj nowe rozmowy, kompaktuj kontekst, dziel zadania. Nie pchaj jednej sesji w nieskończoność.
Na co uważać: Najgorsze awarie (kasowanie bazy bez backupu, rm -rf) statystycznie zdarzają się u kresu okna kontekstowego. Jeśli agent zaczyna zachowywać się „głupio”, przerwij, zamiast dawać kolejny follow-up.
4.Sandboks zamiast zatwierdzania każdej akcji
Na czym polega: Alternatywą dla ryzyka nie jest ręczne klikanie „zatwierdź” przy setkach akcji — to zabija autonomię i sens agenta. Rozwiązaniem jest odizolowane środowisko.
Jak stosować: Uruchamiaj agenta w sandboksie (np. Docker Sandboxes: sbx run claude), by zachować pełną autonomię trybu yolo bez ryzyka dla hosta.
Na co uważać: Ręczne zatwierdzanie daje złudne poczucie kontroli, a w praktyce zmęczenie prowadzi do bezmyślnego akceptowania. Izolacja jest skuteczniejsza niż czujność człowieka.
5.Izolacja systemu plików i procesów chroni hosta
Na czym polega: W sandboksie agent widzi tylko zamontowaną bazę kodu — nie sięgnie do ~/.ssh, nie zabije procesów hosta, nie skasuje plików spoza przestrzeni roboczej.
Jak stosować: Domyślnie montuj tylko bieżący katalog projektu. Sprawdź izolację, prosząc agenta o próbę odczytu plików hosta — powinien dostać „not found”.
Na co uważać: Bez izolacji agent potrafi dla „debugowania” sięgnąć do folderów zupełnie niezwiązanych z projektem, np. do kluczy SSH. Zakładaj, że wszystko dostępne jest zagrożone.
6.Izolacja sieciowa i lista dozwolonych adresów neutralizują prompt injection
Na czym polega: Proxy sandboksu blokuje żądania do adresów spoza listy dozwolonych — zablokowany request zwraca 403, ale w ogóle nie opuszcza kontenera.
Jak stosować: Skonfiguruj allow-listę URL-i, do których agent może się łączyć (repozytoria, docsy, API, które faktycznie testujesz). Resztę blokuj domyślnie.
Na co uważać: Bez tego udany prompt injection może wykraść klucz API i wysłać go pod adres atakującego. Lista dozwolonych to twoja główna obrona przed eksfiltracją danych.
7.Osobny silnik Dockera zapobiega niszczeniu twoich kontenerów
Na czym polega: Sandboks ma własny, zagnieżdżony silnik Dockera i własny zestaw kontenerów — nie dotyka socketu Dockera hosta ani twoich prawdziwych kontenerów.
Jak stosować: Buduj i testuj obrazy wewnątrz sandboksu; utrzymuj osobne środowisko per aplikacja. Główny Docker Desktop zostaw dla rzeczy, których naprawdę używasz.
Na co uważać: Bez tej warstwy agent walczący z konfliktem portów może pozabijać lub usunąć kontenery niezwiązane z projektem. Zweryfikuj, że widzi zagnieżdżony demon, nie host.
8.Tryb --clone daje pełną izolację historii Gita
Na czym polega: Domyślny montaż edytuje pliki bezpośrednio na hoście; > --clone tworzy kopię bazy kodu, więc agent nie rusza twojej historii Gita ani niezacommitowanej pracy.
Jak stosować: Używaj --clone, gdy zlecasz ryzykowne operacje na Gicie albo eksperymenty, których nie chcesz mieszać z lokalnym repozytorium.
Na co uważać: Porzucony git stash i rozwalone merge to realne przypadki. Przy montażu bezpośrednim agent wciąż może namieszać w plikach roboczych — clone eliminuje to całkowicie.
9.Niech agent sam zweryfikuje swoją izolację
Na czym polega: Zanim powierzysz sandboksowi realną pracę, można polecić agentowi serię testów: próba odczytu plików hosta, dosięgnięcia usług hosta, dotknięcia socketu Dockera, ingerencji w kontenery.
Jak stosować: Przy pierwszej konfiguracji uruchom taki zestaw kontroli i sprawdź, że wszystko zwraca „niewidoczne/nieosiągalne”. Możesz też zlecić agentowi całą konfigurację na bazie dokumentacji.
Na co uważać: Nie ufaj konfiguracji na słowo — przetestuj ją empirycznie. Błędnie zamontowany wolumin lub udostępniony socket hosta przekreśla całą izolację.
10.Sprzątanie i darmowość obniżają próg wejścia
Na czym polega: Docker Sandboxes instaluje się jednym poleceniem, działa lokalnie i za darmo, a sbx rm kasuje całą maszynę wirtualną z zawartością, więc nie zapycha dysku.
Jak stosować: Twórz efemeryczne sandboksy per zadanie i usuwaj je po zakończeniu. To dobra higiena — czyste środowisko i brak narastającego bałaganu.
Na co uważać: Łatwość tworzenia kusi do mnożenia instancji — pamiętaj o sbx rm, by nie zostawiać osieroconych VM. Zweryfikuj też, że kasowanie faktycznie zwalnia zasoby.