AIDive

Claude Code w trybie YOLO: czy naprawdę można mu zaufać?

AIDive · Opublikowano

Agenty do kodowaniaBezpieczeństwo AI

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.

Źródła

Najczęstsze pytania

Czym jest tryb YOLO w Claude Code?
Historycznie jest to flaga dangerously-skip-permissions (bypassPermissions): każda akcja wykonuje się bez żadnych kontroli. Od wersji 2.1.228 termin obejmuje też tryb auto, nowy domyślny na płatnych planach, w którym model klasyfikatora sprawdza każdą akcję przed jej wykonaniem.
Czy bezpiecznie jest uruchamiać Claude Code w trybie auto?
Dla samodzielnej pracy na repozytoriach pod kontrolą wersji, bez kluczy produkcyjnych na maszynie, tryb auto plus wbudowany sandbox w trybie automatycznego zezwalania wystarczy. Wszystko, co dotyka bazy danych, konta w chmurze albo tokena produkcyjnego, wymaga izolacji w kontenerze z zaporą wyjściową.
Co domyślnie blokuje klasyfikator Claude Code?
Pobierania przekierowane do powłoki, wdrożenia i migracje produkcyjne, force push, hard reset, terraform destroy, eksfiltrację wrażliwych danych, nieodwracalne usuwanie plików sprzed sesji oraz uruchamianie pętli agenta z flagą pomijającą uprawnienia. Wciąż pozwala na odczyt .env, instalacje z lockfile i push na main.
Jaka jest różnica między klasyfikatorem a sandboxem?
Klasyfikator to kontrola na poziomie pojedynczej akcji: ocenia tekst polecenia, zanim się wykona. Sandbox to granica izolacji wymuszana przez system operacyjny, która ogranicza to, co proces może osiągnąć w trakcie działania — łącznie z procesami potomnymi i skryptami, których klasyfikator nie potrafi odczytać.
Kiedy dangerously-skip-permissions jest akceptowalne?
Wyłącznie wewnątrz jednorazowego, izolowanego środowiska: dev containera z zaporą wyjściową, mikro-VM Docker Sandboxes albo czegoś równoważnego — nigdy bezpośrednio na hoście i nigdy z zamontowanymi kluczami SSH lub poświadczeniami chmurowymi.
Czym jest slopsquatting?
Atak, w którym przeciwnicy z wyprzedzeniem rejestrują nazwy pakietów, które agenci AI mają skłonność halucynować. Gdy agent poleca zmyślony pakiet, instaluje się złośliwa wersja atakującego. Żaden tryb uprawnień ani sandbox tego nie wykrywa, bo instalacja pakietu jest legalną akcją.

Powiązane filmy