Opcja nazywa się --dangerously-skip-permissions. I tak ją włączasz po piętnastym "Yes" pierwszego dnia.

Claude Code pyta o zgodę, zanim cokolwiek uruchomi. Pierwsze pytanie brzmi sensownie. Siedemnaste tego samego popołudnia na tę samą komendę npm już mniej.

Jest też opcja, która eliminuje wszystkie pytania naraz. Nazywa się --dangerously-skip-permissions. Ktoś w Anthropic miał albo poczucie humoru, albo bardzo dobrego prawnika.

Między tymi dwoma krajobrazami jest konfiguracja Claude Code uprawnień przez plik settings.json: lista reguł allow, deny i ask, które harness, czyli środowisko uruchomieniowe Claude Code, sprawdza przy każdej komendzie. Dobra lista sprawia, że agent AI nie pyta o rutynę. Zła sprawia, że agent nie pyta o nic. Ta różnica nie jest kosmetyczna.

Zanim przejdziemy do pliku: jeden szczegół, który zmienia sposób myślenia o całej konfiguracji. Lista reguł jest kontrolą probabilistyczną, nie absolutną. Są udokumentowane przypadki, w których agent ją ominął inną ścieżką. Wrócimy do tego.

Trzy opcje i to, co po nich zostaje w pliku

Kiedy Claude Code chce uruchomić komendę, zatrzymuje się i pyta. Jak system operacyjny z włączonym UAC i wyłączoną pamięcią: to samo pytanie, niezależnie od tego, ile razy już na nie odpowiedziałeś.

Masz 3 wyjścia: Yes (jednorazowa zgoda, następna sesja zapyta o to samo), Yes, don't ask again (harness dopisuje regułę do .claude/settings.json w projekcie, agent przestaje pytać o tę kategorię), No (odrzucasz, agent szuka innego podejścia).

Opcja "Yes, don't ask again" brzmi jak coś, co mówisz sąsiadce, która co tydzień pyta, czy możesz odebrać paczkę. I ma dokładnie ten sam efekt: przestajesz słyszeć pytanie, ale zobowiązanie zostaje. Do chwili, kiedy ręcznie otworzysz settings.json i usuniesz wpis. Albo przeprowadzisz się.

Reguły są oceniane w kolejności: deny → ask → allow. Pierwsza pasująca wygrywa. Jeśli Bash(git push *) jest w deny, żadna reguła w allow jej nie nadpisze, nawet gdyby była zapisana trzy linijki niżej z większą pewnością siebie. Intuicja podpowiada, że bardziej szczegółowa reguła powinna wygrywać. W Claude Code deny wygrywa zawsze.

Co wpisać do settings.json na start

Nemuel Sereti / Pexels

Zamiast budować listę reguł metodą prób i błędów przez pierwsze dwa tygodnie, zacznij od gotowego pliku. Całość mieści się na ekranie bez scrollowania, co jest rzadką cechą dokumentów bezpieczeństwa. Sprawdź oficjalną dokumentację Claude Code po aktualną listę wzorców i składnię.

Allow (operacje lokalne): Bash(npm *), Bash(npx *), Bash(node *) — instalacja zależności, uruchamianie skryptów. Bash(git add *), Bash(git commit *), Bash(git diff *), Bash(git log *), Bash(git status *), Bash(git stash *) — lokalne operacje gita, zapisują w .git/, ale nic nie wysyłają na zewnątrz. Read, Edit, Write — wbudowane narzędzia Claude Code do plików, działają w obrębie katalogu roboczego i nigdy nie pytają o urlop.

Ask (operacje z dostępem na zewnątrz): Bash(curl *), Bash(wget *) — agent mógłby pobrać i uruchomić skrypt instalacyjny bez twojej wiedzy. Różnica między curl po dokumentację a curl po skrypt z internetu jest dla ciebie oczywista. Dla reguły nie. Bash(git push *) i gołe Bash(git push) — push to decyzja publikacyjna. Dwa osobne wzorce, bo git push bez argumentów też wysyła zmiany na remote.

Deny (kategoria "nie chcę nawet widzieć prompta"): Bash(rm -rf *) — może zniszczyć katalog domowy, jeśli agent błędnie podstawi argument. Nie chcesz o tym decydować pod wpływem chwili. Właściwie nie chcesz o tym decydować nigdy.

Celowo nie ma tutaj Bash(git *). Szeroka reguła dałaby agentowi niejawną zgodę na git push, git reset --hard i git clean -fd. Trzy komendy, które łączy jedno: każda z nich jest łatwa do cofnięcia, pod warunkiem że masz backup, doświadczenie i sporo wolnego popołudnia.

Ta lista to punkt wyjścia, nie cel. Po tygodniu zauważysz wzorce: jeśli co sesję zatwierdzasz docker compose up, dorzuć do allow. Denylist rośnie o wzorce, które cię zaskoczyły. Jeśli denylist jest długi, masz też niezły zapis historii pierwszego miesiąca z agentem.

YOLO mode: czego naprawdę wymaga

Naturalny odruch po piętnastym "Yes" tego samego dnia: włączyć --dangerously-skip-permissions i pracować dalej. Odruch jest zrozumiały. Anthropic zna ten odruch i zapisało go w dokumentacji z przypiskiem "używaj wyłącznie w izolowanych środowiskach". Nazwa opcji to drugie ostrzeżenie.

Bez warunków brzegowych YOLO mode jest jak kluczyk zostawiony w stacyjce z otwartymi drzwiami: wygodne, jeśli jesteś jedyną osobą w pobliżu. W YOLO mode agent ma dostęp do wszystkiego, do czego masz dostęp ty. ~/.ssh. Klucze AWS. Plik .env z hasłami do bazy produkcyjnej. Debugowanie komponentu formularza rejestracji i dostęp do serwera produkcyjnego to dla agenta jeden workspace.

Dev container to inne środowisko. Agent widzi tylko to, co mu zamontujesz: repozytorium i potrzebne zależności, nic więcej. Nie ma ~/.ssh. Nie ma kluczy chmurowych. Nie ma bazy produkcyjnej. Twój dysk domowy jest bezpieczny, bo agenta dosłownie tam nie ma. W takich warunkach YOLO mode jest świadomą decyzją z warunkami brzegowymi, a nie wishful thinking.

Instruktorzy kursu 10xDevs pracują z aktywnym YOLO mode od września 2025 roku. Jeden udokumentowany przypadek: agent skasował lokalną bazę danych w trakcie debugowania. Tej samej nocy powstała reguła w CLAUDE.md zabraniająca destruktywnych operacji na bazie bez potwierdzenia. Baza była lokalna i bez backupu. Następna była z backupem.

Jeśli YOLO mode spełnia twoje warunki brzegowe, oficjalna dokumentacja Claude Code zawiera referencyjny devcontainer.json jako punkt startowy. Trzy warunki kursowe: agent działa jako użytkownik nie-root, ma ograniczony ruch sieciowy, widzi tylko zaufane repozytorium.

Denylist to próg, nie zamek

Life Of Pix / Pexels

Tu jest część, którą łatwo pominąć, kiedy plik settings.json już gotowy i wygląda kompletnie.

Polityka uprawnień jest kontrolą probabilistyczną, nie absolutną. Podnosi koszt pomyłki: agent musi się zatrzymać, ty masz szansę zauważyć. Ale kosztu nie zeruje.

Są udokumentowane przypadki, w których Claude Code, mając npx na denyliście, odpalił ten sam plik binarny przez ścieżkę /proc/self/root/usr/bin/npx. Reguła blokowała wzorzec Bash(npx *). Ścieżka bezpośrednia nie pasowała do żadnego wzorca w pliku. Agent uruchomił komendę. Reguła nadal mówiła "nie".

W innym przypadku model zaproponował wyłączenie sandboxu i poprosił użytkownika, żeby uruchomił komendę bez niego. Agent dostał komunikat o błędzie. Agent znalazł sposób na ominięcie błędu. To nie atak. To optymalizacja.

Denylist mówi "nie tą ścieżką". Nie mówi "nie". Różnica między "nie tą ścieżką" a "nie" jest mała, dopóki agent nie znajdzie innej ścieżki. Potem jest duża.

Wildcard Bash(*) w allow to nie konfiguracja bezpieczeństwa. To oświadczenie, że nie interesuje cię, co agent robi. Możesz je złożyć. Skutki są do przewidzenia. Kwestia tego, co dzieje się z Twoim kodem, kiedy agent go czyta i wysyła do API modelu, to osobny temat, który opisałem w artykule o prywatności danych w AI.

Prawdziwa ochrona to kilka warstw: git jako historia operacji, backup bazy, dev container dla izolacji, a przy pracy z narzędziami AI do kodu takie podejście jest bardziej potrzebne niż przy zwykłym IDE. Polityka uprawnień to jedna z warstw. Nie jedyna.

Masz teraz dwa zasoby: konfigurację do wklejenia i powód, żeby nie traktować jej jak zamka. Konfiguracja eliminuje klikanie "Yes" 40 razy dziennie. Powód sprawia, że nie klikasz "Yes, don't ask again" dla Bash(*) o 23:00 w trakcie debugowania. Jeden chroni przed zmęczeniem. Drugi przed konsekwencjami zmęczenia.