claude --dangerously-skip-permissions - jak wyłączyć ciągłe pytania o zgodę w Claude Code, żeby nie narobił szkód

Każdy, kto popracował z Claude Code dłużej niż godzinę, zna ten moment. Agent rozpędza się do dobrego tempa, a potem zatrzymuje się przy każdej komendzie i pyta: czy mogę uruchomić testy? czy mogę zapisać ten plik? czy mogę zainstalować zależność? Przy złożonym zadaniu takich pytań są dziesiątki. Naturalna pokusa to wpisać do wyszukiwarki „jak wyłączyć pytania w Claude Code", znaleźć flagę --dangerously-skip-permissions i już nigdy o niczym nie być pytanym.

Problem polega na tym, że ta flaga rozwiązuje jeden problem (przerywanie pracy) kosztem drugiego, znacznie gorszego: agent z dostępem do shella i systemu plików może teraz zrobić wszystko, bez żadnego hamulca. Skasować nie ten katalog. Wykonać polecenie wklejone do pliku przez kogoś innego. Wysłać zawartość projektu na obcy serwer. Pytanie nie brzmi więc „jak wyłączyć pytania", tylko: jak dać agentowi swobodę działania, nie dając mu jednocześnie możliwości narobienia szkód. Na to jest dobra, przemyślana odpowiedź. I nie jest nią jedna flaga.

1. Co naprawdę robi --dangerously-skip-permissions

Zacznijmy od faktów, a nie od domysłów. Flaga przełącza Claude Code w tryb uprawnień o nazwie bypassPermissions. W opisie z claude --help twórcy nie owijają w bawełnę: flaga jest „zalecana wyłącznie dla sandboxów bez dostępu do internetu". To nie jest marketing, to instrukcja użycia wpisana wprost w narzędzie.

Na pierwszy rzut oka brzmi to absurdalnie - przecież Claude Code bez sieci nawet nie połączy się z modelem. Problem w tym, że „no internet access" to mylący skrót myślowy. Nie chodzi o komputer wypięty z sieci, tylko o taki, który ma ściśle ograniczone połączenia wychodzące: internet nie tyle „wyłączony", co zawężony do krótkiej listy dozwolonych adresów. W praktyce sandbox z góry blokuje każde połączenie na zewnątrz, a potem odblokowuje wyłącznie te adresy, których agent faktycznie potrzebuje: serwery API Anthropic (bez nich model nie odpowie, więc Claude Code w ogóle nie zadziała), a zwykle też GitHub i rejestr pakietów (npm, PyPI). Cała reszta internetu jest dla agenta niedostępna - próba wysłania Twojego kodu na obcy serwer albo ściągnięcia skryptu spoza listy zostaje po prostu odrzucona na poziomie sieci, zanim cokolwiek wyjdzie z maszyny. Dzięki temu nawet agent działający zupełnie bez pytań nie ma technicznej możliwości wyprowadzić danych na zewnątrz. To właśnie ten firewall z listą dozwolonych adresów, który stawiamy w sekcji 6, nadaje fladze bypass sens.

W tym trybie znikają wszystkie interaktywne pytania, łącznie z tymi, które w innych trybach pojawiają się nawet przy włączonej automatyzacji - czyli zapisami do tak zwanych ścieżek chronionych: katalogu .git, konfiguracji samego Claude (.claude), plików edytora (.vscode, .idea) czy plików startowych powłoki (.bashrc, .zshrc). Normalnie Claude pyta przed dotknięciem tych miejsc, bo przypadkowa zmiana w nich potrafi zepsuć repozytorium albo własną konfigurację agenta. Z flagą bypass nie pyta o nic z tego.

Czego flaga NIE wyłącza - trzy twarde bezpieczniki

Tu jest niespodzianka, o której mało kto wie. Mimo dramatycznej nazwy, kilka bezpieczników działa zawsze, nawet z tą flagą:

• Odmowa startu jako root. Na Linuksie i macOS Claude Code po prostu nie uruchomi się w tym trybie, jeśli działasz jako root lub przez sudo. To celowa bariera: agent z prawami roota i bez pytań to przepis na katastrofę systemową.
• Kasowanie korzenia i katalogu domowego. Polecenia w rodzaju rm -rf / czy rm -rf ~ nadal wywołają pytanie jako bezpiecznik (circuit breaker) przeciw zwykłemu błędowi modelu, nie przeciw złośliwości.
• Reguły ask z konfiguracji. Jeśli w settings.json oznaczysz jakąś operację jako wymagającą pytania, Claude zapyta o nią nawet w trybie bypass.

To ważne, ale nie zmienia konkluzji. Te bezpieczniki chronią przed grubymi pomyłkami, a nie przed całą resztą: nadpisaniem plików projektu, wysłaniem danych na zewnątrz, wykonaniem polecenia, które wstrzyknął ktoś inny w treści pliku albo strony, którą agent przeczytał. Dlatego flaga sama w sobie nie jest rozwiązaniem; jest ostatnim elementem układanki, który ma sens dopiero w izolacji. Zanim do niej dojdziemy, zobaczmy, czego właściwie bronią te pytania.

2. Dlaczego Claude w ogóle pyta - to nie biurokracja, to zabezpieczenie

Pytanie o zgodę bywa irytujące, ale pełni konkretną funkcję: to moment kontroli. Zanim agent uruchomi komendę, masz okazję ją przeczytać i zdecydować. W domyślnym trybie Claude Code bez pytania wykonuje tylko operacje odczytu (czytanie plików, przeszukiwanie repozytorium). Każda akcja, która coś zmienia (zapis pliku, polecenie shella, połączenie z zewnętrznym API), zatrzymuje się i czeka na Ciebie.

Druga opcja na liście, „Yes, and don't ask again", to najprostszy sposób na ograniczenie pytań bez sięgania po cokolwiek niebezpiecznego. Zatwierdzasz raz, a Claude do końca sesji nie pyta już o ten typ operacji. Po kilkunastu minutach pracy nad konkretnym zadaniem lista takich „cichych zgód" sama domyka większość powtarzalnych pytań. To jednak rozwiązanie na jedną sesję. Jeśli chcesz coś trwałego i przenoszalnego między projektami, potrzebujesz konfiguracji. I tu zaczyna się prawdziwa robota.

3. Mapa trybów uprawnień

Zanim zaczniesz konfigurować, warto znać pełny zestaw trybów. „Pyta o wszystko" i „nie pyta o nic" to tylko dwa skrajne punkty na skali, na której jest sześć pozycji:

Tryby przełączasz w locie klawiszem Shift+Tab albo ustawiasz na starcie flagą --permission-mode. Najczęściej używane to default (do pracy wymagającej uwagi), acceptEdits (gdy chcesz przejrzeć zmiany dopiero po fakcie przez git diff) i plan (gdy chcesz, żeby Claude najpierw rozpoznał kod i zaproponował plan, niczego nie zmieniając). Dla tematu tego artykułu kluczowe są jednak dwa ostatnie: auto i bypassPermissions. To one realizują „nie przeszkadzaj mi co chwilę", ale na dwa diametralnie różne sposoby. Sam zestaw trybów, przełączanie ich w locie i mechanizm auto-accept omawiamy szczegółowo w osobnym artykule: Tryby uprawnień w Claude Code - Shift+Tab, auto-accept i prompt zgody.

Tryb ustawisz też na stałe w pliku ustawień:

// ~/.claude/settings.json - domyślny tryb dla wszystkich sesji
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

4. Warstwa 1 - reguły allow, ask i deny

Najtańsza w użyciu warstwa to statyczne reguły w settings.json. Idea jest prosta: zamiast pytać Cię o każdą operację, Claude porównuje ją z trzema listami. Reguła allow przepuszcza operację bez pytania. Reguła deny blokuje ją twardo. Reguła ask wymusza pytanie. Co ważne: deny zawsze wygrywa z allow, więc blokada groźnych poleceń jest nadrzędna wobec wszelkich zgód.

W praktyce konfiguracja wygląda tak, że przepuszczasz nudną i bezpieczną rutynę, a twardo blokujesz to, czego agent nie powinien tknąć:

// .claude/settings.json - w repozytorium, dla całego zespołu
{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Read(./src/**)",
      "Edit(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git commit:*)"
    ]
  }
}

Powyższa konfiguracja sama w sobie zdejmuje większość pytań, których i tak zawsze byś zatwierdzał (status gita, testy, edycja kodu w src), a jednocześnie nie pozwala agentowi usuwać rekurencyjnie, wypychać zmian na zdalne repozytorium, ściągać czegokolwiek przez curl ani czytać plików z sekretami. Reguły mają swoją hierarchię: od ustawień organizacji (najwyższy priorytet) przez globalne i projektowe po lokalne nadpisania. Pełny opis składni wzorców, hierarchii plików oraz hooków znajdziesz w osobnym artykule: Claude Code Permissions - system uprawnień, settings.json i hooks.

5. Warstwa 2 - auto mode, czyli złoty środek

To jest właściwa odpowiedź na pytanie z tytułu. Auto mode (dostępny od Claude Code 2.1.83) pozwala agentowi pracować bez rutynowych pytań, ale nie zdejmuje hamulca: zastępuje pytanie do Ciebie sprawdzeniem przez osobny model-klasyfikator. Przed każdą akcją klasyfikator sprawdza, czy nie wykracza ona poza Twoją prośbę, czy nie celuje w nieznaną infrastrukturę i czy nie wygląda na sterowaną przez wrogą treść, którą Claude przeczytał. Jeśli coś jest podejrzane, blokuje to, zanim się wykona.

Domyślnie klasyfikator blokuje między innymi:

• pobieranie i wykonywanie kodu z sieci (klasyczne curl ... | bash),
• wysyłanie wrażliwych danych na zewnętrzne adresy,
• wdrożenia produkcyjne i migracje baz,
• masowe kasowanie w chmurowych magazynach plików,
• nadawanie uprawnień (IAM, dostęp do repozytorium),
• nieodwracalne niszczenie plików, które istniały przed sesją,
• force push i wypychanie wprost na main,
• git reset --hard, git clean -fd i podobne polecenia kasujące niezapisane zmiany,
• terraform destroy, pulumi destroy i odpowiedniki niszczące infrastrukturę.

Jednocześnie bez pytania przechodzą rzeczy bezpieczne: operacje na plikach w katalogu roboczym, instalacja zależności zadeklarowanych w plikach manifestu, odczyt plików .env i wysłanie poświadczeń do pasującego API, zapytania HTTP tylko do odczytu czy wypchnięcie na gałąź, na której pracujesz. Efekt: pracujesz długimi, nieprzerywanymi odcinkami, a mimo to ktoś (a właściwie coś) cały czas patrzy na ręce.

Granice, które wypowiadasz w rozmowie

Jest jeszcze jedna funkcja, której nie ma żaden inny tryb. Klasyfikator traktuje granice, które wypowiesz w czacie, jako sygnał blokady. Jeśli napiszesz „nie wypychaj zmian" albo „poczekaj z wdrożeniem, aż sprawdzę", zablokuje pasujące akcje, nawet gdyby domyślne reguły je przepuściły. Granica obowiązuje, dopóki jej nie cofniesz. Jest jednak haczyk: granice nie są zapisywane jako twarda reguła: klasyfikator odczytuje je z transkryptu rozmowy, więc po kompaktowaniu kontekstu (gdy starsze wiadomości znikają) granica może przepaść. Po twardą gwarancję sięgnij po regułę deny z poprzedniej sekcji.

Auto mode ma też własny bezpiecznik: jeśli klasyfikator zablokuje akcję trzy razy z rzędu albo dwadzieścia razy łącznie w sesji, tryb sam się wstrzymuje i Claude wraca do pytania o zgodę. To chroni przed zapętleniem agenta, który raz po raz próbuje czegoś, czego nie wolno. Włączysz auto mode tak samo jak inne tryby: klawiszem Shift+Tab w trakcie sesji albo na stałe w globalnym pliku ustawień (defaultMode: "auto" w ~/.claude/settings.json; uwaga: w plikach projektu to ustawienie jest celowo ignorowane, żeby repozytorium nie mogło samo sobie przyznać autonomii).

6. Warstwa 3 - izolacja, czyli kiedy bypass naprawdę ma sens

Dochodzimy do flagi z tytułu. --dangerously-skip-permissions zdejmuje całą kontrolę poza regułami ask, więc, jak ujmuje to dokumentacja, jedyną rzeczą, która ogranicza wtedy agenta, jest granica izolacji. Wniosek jest prosty: tej flagi nie uruchamiasz na gołym hoście. Uruchamiasz ją wewnątrz środowiska, którego agent nie jest w stanie uszkodzić. Masz do wyboru kilka poziomów:

• Wbudowany sandbox Bash (/sandbox) - ogranicza dostęp do plików i sieci dla każdej komendy shella, używając mechanizmów systemu (Seatbelt na macOS, bubblewrap na Linuksie). Lekki, ale ogranicza tylko Bash - nie obejmuje serwerów MCP ani hooków.
• Sandbox runtime (@anthropic-ai/sandbox-runtime) - opakowuje cały proces Claude Code w tę samą izolację, więc ogranicza wszystkie narzędzia, hooki i serwery MCP, nie tylko Bash. Nie wymaga Dockera.
• Dev container - Claude Code działa wewnątrz kontenera Dockera jako użytkownik bez praw roota, a Twój projekt jest do niego podmontowany. Komendy wykonują się w kontenerze, a edycje plików widać u Ciebie na hoście.
• Dedykowana maszyna wirtualna - najsilniejsza separacja, z własnym jądrem systemu. Do pracy z kodem, któremu zupełnie nie ufasz.

Referencyjny dev container od twórców Claude Code dokłada do tego firewall. To nie jest nic, co masz u siebie domyślnie - cała konfiguracja jest częścią oficjalnego katalogu .devcontainer w repozytorium Claude Code na GitHubie (możesz go skopiować do swojego projektu). Leży tam skrypt init-firewall.sh, który ustawia politykę domyślnej blokady całego ruchu wychodzącego i przepuszcza tylko adresy z listy dozwolonych (GitHub, rejestr npm, API Anthropic). Dzięki temu nawet agent działający bez pytań nie wyśle danych w dowolne miejsce w sieci. Skrypt na koniec sam weryfikuje, czy firewall działa:

To właśnie dlatego dev container może uruchamiać Claude Code z flagą bypass do pracy bez nadzoru: blokada nieznanego ruchu wychodzącego ogranicza to, do czego sesja w ogóle może sięgnąć. Tu też domyka się kółko z sekcji pierwszej: Claude Code odmawia startu z tą flagą jako root, więc w kontenerze trzeba uruchamiać go jako użytkownik bez praw roota (parametr remoteUser).

7. Kiedy co - matryca decyzji

Zbierzmy to w jedną regułę praktyczną: im większą swobodę dajesz agentowi, tym mocniejsza musi być granica wokół niego. Dobór wygląda tak:

Zwróć uwagę, że auto mode pokrywa większość realnych potrzeb „niech działa sam". Po flagę bypass sięga się rzadziej, niż się wydaje, głównie w pipeline'ach CI i w jednorazowych, w pełni izolowanych przebiegach. Dla zespołu, który chce z góry odebrać możliwość użycia bypass, jest do tego wyłącznik w ustawieniach zarządzanych:

// managed-settings.json (np. /etc/claude-code/) - najwyższy priorytet,
// nie do nadpisania przez użytkownika ani repozytorium
{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "defaultMode": "auto"
  }
}

8. Złota zasada i checklista

Cała ta wiedza sprowadza się do jednego zdania, które warto zapamiętać: swobodę agenta równoważy się granicą wokół niego, nie zaufaniem do niego. Zanim uruchomisz Claude Code w trybie autonomicznym, przejdź przez krótką listę:

1. Zacznij od auto mode, nie od bypass. W 90% przypadków „niech pracuje sam" to auto mode, nie --dangerously-skip-permissions.
2. Ustaw reguły deny dla rzeczy nieodwracalnych. wypychanie na produkcję, kasowanie, dostęp do sekretów. Twardo zablokuj te rzeczy, nawet jeśli ufasz agentowi.
3. Flagę bypass odpalaj tylko w izolacji. Dev container z firewallem, sandbox runtime albo VM. Nigdy na gołym hoście z dostępem do produkcji.
4. Nie wpuszczaj sekretów do środka. Żadnego montowania ~/.ssh ani kluczy chmury do kontenera. Używaj tokenów krótkożyciowych, ograniczonych do repozytorium.
5. Pracuj tylko z zaufanym kodem. Obce repozytorium = osobna, dedykowana maszyna wirtualna.
6. Obserwuj, co agent robi. Nawet z hamulcami przejrzyj od czasu do czasu, co się wykonało. Wyłapiesz wzorce, których nie przewidziałeś.

Najgorsza odpowiedź na „pyta co trzy sekundy" to wyłączenie wszystkich pytań na maszynie, na której agent może coś zepsuć. Najlepsza to złożenie kilku tanich warstw: reguł, które przepuszczają nudne i blokują groźne; auto mode, który sprawdza resztę; i izolacji, która zamienia „może narobić szkód" w „może narobić szkód najwyżej w piaskownicy". Tak robi się to profesjonalnie: agent pracuje pełną parą, a Ty śpisz spokojnie.

Permissions, auto mode, reguły allow/deny, izolacja (dev container, sandbox, VM), hooki, MCP i systemy multi-agent - na żywym kodzie podczas trzydniowego szkolenia. Prowadzi Łukasz Matuszewski, a szkolenie ma termin gwarantowany, więc odbędzie się niezależnie od liczby zgłoszeń.

Claude Code - od zera do zespołu agentów AI

✕