Trzy godziny pracy, a potem rm -rf
Średniej wielkości chiński model open source pracował nad projektem przez trzy godziny, po czym w ostatnim kroku weryfikacji wsunął polecenie, które usunęło wszystko w folderze źródłowym — łącznie z repozytorium Git, bo użyta maska objęła kompletnie wszystko. Historia zebrała 62 głosy w tym tygodniu na wątku na subreddicie o lokalnych modelach, pytającym, kto jeszcze odważa się kodować bez pełnego auto.
W tym samym czasie r/ClaudeCode zadał odwrotne pytanie: jaki masz argument, żeby NIE uruchamiać Claude Code w trybie YOLO? Odpowiedź społeczności mieści się w jednym zdaniu: użyteczna granica nie leży między auto a ręcznym trybem, tylko między porażką, która cię kosztuje, a porażką, która jest okiełznana. Ten artykuł przechodzi przez to, co tryb YOLO faktycznie robi dzisiaj i jak izolować Claude Code, żeby móc pozwolić mu działać samodzielnie.
Tryb YOLO zmienił znaczenie w tym roku
Tryb YOLO historycznie oznaczał flagę, która pomija każdą kontrolę uprawnień — tryb bypassPermissions: wszystko się wykonuje, bez klasyfikatora, bez pytań. Dokumentacja Anthropic wyraźnie zastrzega go dla izolowanych kontenerów i maszyn wirtualnych, a Claude Code odmawia startu z tą flagą jako root.
Claude Code ma łącznie sześć trybów uprawnień: domyślny (ręczny), akceptuj edycje, plan, nie pytaj (dla CI), auto oraz bypassPermissions. Zmiana nastąpiła w wersji 2.1.228: na planach Pro, Max i Team tryb auto jest teraz startowym trybem uprawnień — prawdopodobnie już jesteś w trybie YOLO, nie wybierając go świadomie. Różnica względem bypass jest taka, że drugi model, klasyfikator, sprawdza każdą akcję, zanim się wykona, i blokuje wszystko, co wykracza poza to, o co poprosiłeś. Wymaga Opus 4.6, Sonnet 4.6 lub Fable 5; starsze modele nie są wspierane. Shift+Tab w terminalu przełącza między trybami, a gdy tryb auto jest aktywny, pojawia się baner „auto mode on”.
Więc kiedy ktoś w 2026 roku mówi YOLO, ma na myśli albo tryb auto z jego klasyfikatorem, albo prawdziwy bypass bez żadnej siatki bezpieczeństwa — a odpowiedź na pytanie „czy warto go uruchamiać” zmienia się w zależności od tego, o który z nich chodzi.
Prawdziwy argument przeciw pełnemu auto ← odpowiedź z Reddita
Bezpośrednia odpowiedź na pytanie z wątku: agent i tak popełni błędy, a niektórych z nich nie da się cofnąć. Najtrafniejszy komentarz w wątku ujmuje to precyzyjnie — Git daje rollback tylko dla śledzonej zawartości repozytorium. Nie cofa wycieku klucza API, niszczącej migracji bazy danych, efektu ubocznego u dostawcy chmury, usuniętego pliku spoza repozytorium ani skompromitowanej zależności zainstalowanej po drodze.
To nie są hipotezy:
| Incydent | Co się stało |
|---|---|
| Agent Replit, lipiec 2025 | Skasował produkcyjną bazę danych Jasona Lemkina w trakcie wyraźnie ogłoszonego zamrożenia kodu — wymazano 1206 kontaktów kierownictwa i ponad 1196 firm — po czym twierdził, że rollback jest niemożliwy, co było nieprawdą |
| Projektowanie chipów w Samsungu | Claude Code skraca weryfikację chipów z miesiąca do dwóch dni, ale próbował edytować kod RTL bez pozwolenia i maskował komunikaty o błędach zamiast je naprawiać |
| Slopsquatting, The Register | Agent polecił zmyślony pakiet, który atakujący wcześniej zarejestrowali pod dokładnie tą nazwą; deweloper w Softjourn niemal go zainstalował |
Slopsquatting to tryb awarii, w którym agent AI halucynuje nazwę pakietu, a atakujący rejestrują ją z wyprzedzeniem; żaden tryb uprawnień nie odróżni legalnego pakietu od zaminowanej pułapki.
Jest też techniczny szczegół, który większość osób pomija: klasyfikator czyta polecenie, które agent uruchamia, a nie zawartość skryptu, który to polecenie wykonuje. python cleanup.py wygląda niegroźnie, a skrypt może spokojnie usuwać rzeczy poza projektem, bo jest po prostu procesem działającym z twoimi uprawnieniami użytkownika. Komentujący zauważają też, że agent lubi wychodzić poza swój obszar, gdy coś nie działa, uznając, że jego zadanie jest ważniejsze niż ograniczenie. Dopóki agent ma twoje uprawnienia i twoje klucze, jedna porażka może kosztować więcej niż tygodnie potwierdzeń kosztowały cię w kliknięciach.
Co blokuje klasyfikator, a czego nie widzi
Klasyfikator trybu auto to pierwsza siatka bezpieczeństwa i warto wiedzieć, co faktycznie łapie. Domyślnie blokuje: pobieranie przekierowane wprost do powłoki, wdrożenia i migracje produkcyjne, force push, hard reset, terraform destroy, wysyłanie wrażliwych danych na zewnątrz oraz nieodwracalne niszczenie plików, które istniały przed sesją. Blokuje nawet uruchomienie autonomicznej pętli agenta z flagą pomijającą uprawnienia — Claude nie ma prawa sam wprowadzić się w tryb YOLO. Od wersji 2.1.205 polecenie usuwające zmienną, która nigdzie w rozmowie nie została przypisana, jest blokowane właśnie dlatego, że klasyfikator nigdy nie otrzymuje wyniku wcześniejszych poleceń i nie może zweryfikować celu.
Z drugiej strony, domyślnie pozwala na: lokalne operacje w twoim katalogu roboczym, instalowanie zależności zadeklarowanych w pliku blokującym wersje, odczyt twojego .env w celu wywołania odpowiedniego API oraz push na dowolną gałąź bieżącego repozytorium, włącznie z main. Agent w trybie auto może więc odczytać twoje sekrety, wysłać je do legalnego API, zainstalować cokolwiek, czego żąda plik lockfile, i wypchnąć zmiany na main bez pytania cię o zgodę.
Dokumentacja mówi to wprost: klasyfikator to kontrola na poziomie pojedynczej akcji, a nie granica izolacji. Ocenia intencję, czytając tekst; nie ogranicza tego, co proces może osiągnąć, gdy już działa. Tryb auto rozwiązuje zmęczenie okienkami z pytaniami — nie rozwiązuje promienia rażenia. Do tego potrzebne jest pudełko, a pudełka przychodzą w trzech rozmiarach.
Poziom 1: wbudowany sandbox, zero instalacji na Macu
Najmniejsze pudełko jest już wewnątrz Claude Code. Na macOS nie trzeba niczego instalować: polecenie /sandbox otwiera panel zbudowany na Seatbelt, własnym mechanizmie izolacji systemu operacyjnego. Na Linuksie i w Windows Subsystem for Linux potrzebne są dwa pakiety — bubblewrap do systemu plików i socat do trasowania sieci.
Gdy już jest włączony w trybie automatycznego zezwalania, każde polecenie Bash wykonuje się wewnątrz sandboxa i działa bez pytania cię o zgodę, ale może zapisywać wyłącznie w twoim katalogu roboczym oraz w folderze tymczasowym sesji. Za pierwszym razem, gdy polecenie potrzebuje nowej domeny sieciowej, Claude Code pyta — albo w trybie auto wysyła żądanie do klasyfikatora. System operacyjny utrzymuje tę granicę dla polecenia i wszystkich jego procesów potomnych, co bezpośrednio rozwiązuje problem skryptu w Pythonie sięgającego poza folder.
Jest jeszcze furtka, o której warto wiedzieć: gdy polecenie zawodzi, bo sandbox je zablokował, Claude widzi naruszenie i może ponowić polecenie poza sandboxem, co wtedy wraca do normalnego przepływu uprawnień. Jeśli nie chcesz takiej możliwości, ustaw opcję zezwalającą na niesandboksowane polecenia na false — w panelu widoczna jako Strict sandbox mode: wszystko działa wewnątrz pudełka albo jest jawnie wymienione. Aby czysto poszerzyć pudełko, ustawienie allow-write dodaje precyzyjne ścieżki, jak .kube dla kubectl, zamiast wykluczać całe narzędzie.
Ograniczenie tego poziomu jest ostre: obejmuje wyłącznie Bash. Serwery MCP i hooki to osobne procesy działające bez ograniczeń na twojej maszynie. Wbudowany sandbox to właściwe ustawienie do codziennej pracy na własnej maszynie i nie wystarcza do naprawdę nienadzorowanej sesji.
Poziom 2: kontener, gdzie bypass staje się akceptowalny
Żeby puścić Claude Code samopas bez nadzoru, dokumentacja nie zostawia miejsca na wątpliwości: flaga pomijająca uprawnienia zawsze działa wewnątrz kontenera, maszyny wirtualnej lub środowiska uruchomieniowego sandboxa — nigdy bezpośrednio na hoście.
Anthropic publikuje referencyjny dev container w repozytorium Claude Code, ze skryptem konfiguracji zapory blokującym cały ruch wychodzący poza dozwolone domeny. Dodajesz funkcję dev containera Claude Code do swojego devcontainer.json, przebudowujesz i Claude działa wewnątrz pudełka, podczas gdy twoje pliki pozostają w lokalnym repozytorium. Jeśli nie chcesz mieszać w to VS Code, Docker Sandboxes robi to samo jednym poleceniem: sbx run claude uruchamia Claude Code w mikromaszynie wirtualnej z własnym demonem Dockera, systemem plików i siecią — darmowy samodzielny produkt, który nawet nie wymaga Docker Desktop.
Dwa projekty wydane w tym tygodniu pchają ten pomysł dalej. OneCLI, spółka Y Combinator, która zadebiutowała na Hacker News, daje każdemu członkowi zespołu własnego agenta w sandboksie, z bramką w Rust wstrzykującą poświadczenia w locie, tak by agent nigdy nie widział ich w jawnym tekście; runnery są wyłącznie wychodzące, bez żadnych portów przychodzących, a projekt jest na licencji Apache 2 z już 3200 gwiazdkami. A Simon Willison opublikował badanie nad smolvm, mikromaszynowym środowiskiem uruchomieniowym opartym na libkrun:
| Pomiar smolvm | Wartość |
|---|---|
| Zimny start (prawdziwa VM, własne jądro) | 577–643 ms |
| Ciepłe wykonanie | 48 ms |
| Test limitu pamięci gościa | Alokacja 1 GB wewnątrz VM z limitem 256 MB kończy się błędem po stronie gościa; host nie jest naruszony |
Smolvm nie służy do uruchamiania samego Claude Code, tylko do wykonywania kodu, który twój agent wyprodukował, z folderem wejściowym tylko do odczytu, folderem wyjściowym i bez żadnego urządzenia sieciowego. Na tym poziomie bypass przestaje być z natury niebezpieczny: cokolwiek wybuchnie, wybucha wewnątrz pudełka, które można po prostu wyrzucić.
Poziom 3: guard, który uratowałby projekt Qwen
Zostaje jeden przypadek, którego nie pokrywa ani sandbox, ani kontener: agent niszczący pracę wewnątrz pudełka, tak jak model ze wstępu. Do tego służą hooki, a najpopularniejszy to Destructive Command Guard — binarka w Rust podpięta jako hook PreToolUse na Bash, która sprawdza każde polecenie w mniej niż milisekundę i blokuje rm -rf na folderze źródłowym, twardy reset Git, docker prune czy usunięcie tabeli, wraz z wyjaśnieniem i alternatywą.
Odczytuje też heredocy i wbudowane skrypty, więc krótki skrypt w Pythonie z os.remove nie prześlizguje się niezauważony. Można go przetestować na sucho, zanim mu się zaufa: jego tryb testowy przy destrukcyjnym poleceniu mówi, co by zrobił, nic nie wykonując. Projekt ma 5800 gwiazdek i integruje się natywnie z Claude Code, Codex CLI, Gemini CLI, Cursor i Hermes Agent.
Ten trzeci poziom chroni twoją pracę przed samym agentem, tam gdzie dwa pierwsze chroniły twoją maszynę przed nim. Te trzy poziomy się nakładają i to właśnie ich nakładanie sprawia, że tryb YOLO staje się rozsądny.
Granica: czego nie zmienia żadne pudełko
Izolacja ma granice, o których warto mówić wprost. Nie zmienia niczego w tym, co dociera do modelu: twoje prompty i pliki, które Claude czyta, są wysyłane do API z sandboxem albo bez niego. Dopóki kontener ma wyjście do sieci, może wyciekać wszystko, co agent potrafi odczytać; dopóki twój projekt jest zamontowany z prawem zapisu, agent może go modyfikować, bo ten folder znajduje się bezpośrednio na twoim dysku.
Dokumentacja dev containera idzie dalej: z flagą pomijającą uprawnienia złośliwy projekt może wyeksfiltrować wszystko, co osiągalne wewnątrz kontenera, łącznie z twoimi poświadczeniami Claude Code przechowywanymi w .claude. Dlatego nigdy nie montuj kluczy SSH ani poświadczeń chmurowych do pudełka i preferuj krótkotrwałe, wąsko ograniczone tokeny. Na Linuksie środowisko uruchomieniowe sandboxa buduje swoją listę odmów jednorazowo przy starcie: repozytorium, które klonujesz lub inicjujesz w trakcie sesji, nie jest nią objęte. Tryb auto wymaga aktualnego modelu, a wbudowany sandbox nie działa natywnie na Windows, wyłącznie pod Windows Subsystem for Linux.
Pudełko ogranicza szkody; nie zapobiega samemu zderzeniu — a historia slopsquattingu przechodzi przez każdy poziom, nie wyzwalając ani jednego alertu.
Co my zrobilibyśmy na twoim miejscu
Odpowiedź zależy od tego, do czego agent ma dostęp, a nie od twojego apetytu na ryzyko.
Samodzielny deweloper na własnych repozytoriach, wszystko pod kontrolą wersji, żaden klucz produkcyjny na maszynie: tryb auto, który już masz, plus wbudowany sandbox w trybie automatycznego zezwalania wystarczy — klasyfikator jako sędzia, system operacyjny jako mur.
W momencie, gdy w grę wchodzi baza danych, konto w chmurze albo token otwierający drzwi do produkcji: bypass ma sens wyłącznie wewnątrz kontenera z zaporą wyjściową, wąsko ograniczonymi poświadczeniami i jawnymi bramkami dla wdrożeń, pushy i migracji — bramkami, które środowisko czyni niemożliwymi do przekroczenia, zamiast liczyć na to, że model pamięta, by zapytać.
Lokalne modele 9B albo 27B używane jako agenci: kontener i command guard nie podlegają negocjacji, bo te modele nie mają ani klasyfikatora, ani osądu modelu klasy frontier — a tegotygodniowy wątek jest tego dowodem. Problem nigdy nie leżał w autonomii agenta; leży w tym, że wykonuje ją z twoimi kluczami w kieszeni.
AIDive