Claude Code dangerously-skip-permissions: kiedy jest bezpieczne?

--dangerously-skip-permissions wyłącza pytania o uprawnienia w Claude Code na całą sesję. To to samo co --permission-mode bypassPermissions, a dokumentacja Anthropic sama mówi, żeby używać go tylko w kontenerach lub maszynach wirtualnych, gdzie Claude Code nie może wyrządzić szkód. Trzymamy się tego dosłownie: na laptopie programisty agent pracuje w ramach reguł allow, ask i deny oraz hooków, a pełny bypass działa tylko w odizolowanym środowisku z własnymi kontami.

Krótka odpowiedź dla CTO: proszę nie zakazywać flagi, tylko zdecydować, gdzie jest dozwolona. Reguły na laptop, hooki na to, czego reguły nie widzą, izolacja dla wszystkiego, co działa bez nadzoru.

Co naprawdę wyłącza --dangerously-skip-permissions?

Claude Code ma sześć trybów uprawnień. Flaga wybiera ostatni z nich:

„Wszystko” ma wyjątki i one są ważne. Według dokumentacji trybów uprawnień żaden tryb nie zatwierdza automatycznie narzędzi pasujących do jawnej reguły ask, rozpoznanych usunięć rm krytycznych ścieżek ani narzędzi, które potrzebują człowieka, takich jak AskUserQuestion. Hooki też dalej działają. Bypass usuwa natomiast pytanie przed zapisem do chronionych ścieżek, takich jak .git i .claude, które wszystkie inne tryby zachowują.

Bypass to więc nie „brak reguł”. To „brak człowieka w pętli”. Pytanie brzmi, czy w tej pętli jest coś innego.

Jak decydują reguły allow, ask i deny?

Reguły są w settings.json, w trzech listach. To skrócona wersja z naszego publicznego Claude Code production starter:

{
  "permissions": {
    "allow": ["Bash(pnpm check)", "Bash(pnpm test:*)", "Bash(bash scripts/gate.sh:*)"],
    "ask": ["Bash(git push:*)", "Bash(gh pr merge:*)", "Bash(vercel --prod:*)", "Bash(wrangler deploy:*)"],
    "deny": ["Read(**/.env)", "Read(**/*.pem)", "Bash(git push --force:*)", "Bash(git reset --hard:*)", "Bash(psql:*)"]
  }
}

Kształt jest polityką. Allow dla tego, czego agent potrzebuje, żeby sprawdzić własną pracę. Ask dla wszystkiego, co opuszcza maszynę: push, merge, wdrożenie. Deny dla sekretów, przepisywania historii i bezpośredniego dostępu do bazy danych.

Claude Code ocenia najpierw deny, potem ask, potem allow, i wygrywa pierwsze dopasowanie. Deny nigdy nie da się otworzyć węższym allow. Działa to też między plikami: deny w repozytorium jest silniejszy niż allow w czyichś osobistych ustawieniach. Dlatego reguły zespołu należą do .claude/settings.json w repozytorium, a osobiste skróty do ~/.claude/settings.json.

To zdanie jest powodem, by każde „nigdy nie rób X” przenieść z CLAUDE.md do reguły albo hooka.

Czego reguła uprawnień nie widzi?

Reguła dopasowuje tekst polecenia. Trzy rzeczy jej umykają:

• Gałąź. Bash(git push:*) nie odróżni git push origin feat/x od git push origin main. Pytanie przy każdym pushu sprawia, że ludzie zaczynają klikać „tak” bez czytania.
• Dostęp pośredni. Dokumentacja mówi to wprost: reguły deny dla Read nie obejmują skryptu w Pythonie czy Node, który sam otwiera plik, a deny dla Bash nie pasuje do tego samego programu wewnątrz sh -c.
• Kontekst. Reguła nie wie, kto uruchamia sesję ani w jakim repozytorium pracuje.

Tu właśnie przydaje się hook PreToolUse. Dostaje całe wywołanie narzędzia jako JSON, może wykonać dowolną logikę, a exit 2 blokuje wywołanie, zanim w ogóle zostaną ocenione reguły uprawnień. Rdzeń naszego push gate, w skrócie:

CMD=$(jq -r '.tool_input.command // empty')
[[ "$CMD" != *"git push"* ]] && exit 0
BRANCH=$(git -C "${CLAUDE_PROJECT_DIR:-.}" branch --show-current 2>/dev/null)
if [[ "$CMD" =~ [[:space:]:](main|master)([[:space:]]|$) || "$BRANCH" == "main" ]]; then
  echo "Pushing to main is not allowed. Push a branch and open a PR." >&2
  exit 2
fi

Hook potrzebuje własnego testu, inaczej może zamilknąć. Jak to się dzieje i jak to wychwycić, opisujemy w artykule Hooki Claude Code, które po cichu nic nie robią.

Kiedy pomijanie uprawnień jest naprawdę bezpieczne?

Gdy granicą jest samo środowisko. Uruchomienia bez nadzoru używają --permission-mode bypassPermissions i --disallowedTools AskUserQuestion ExitPlanMode, bo nikt nie odpowie na pytanie. To, co czyni to akceptowalnym, to nie flaga, tylko to, co ją otacza. Dla agenta AI, który działa sam i realizuje issues, zalecamy:

Nawet w bypassie merge zostaje w rękach człowieka. Agent otwiera pull request, ochrona gałęzi wymaga zatwierdzenia, a zatwierdzenie nigdy nie należy do agenta.

Recenzent w CI to drugi biegun. Też działa bez nadzoru, ale zamiast bypassu dostaje jawną listę narzędzi:

claude_args: --allowed-tools "Read,Glob,Grep,Bash(git diff:*),Bash(git log:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Może czytać diff i komentować. Nie może edytować, pushować ani mergować, więc nie ma czego omijać.

A wbudowany sandbox?

Claude Code ma sandbox na poziomie systemu operacyjnego, który ogranicza, co polecenia powłoki mogą czytać, zapisywać i z czym łączyć się w sieci, łącznie z ich procesami potomnymi. To właściwa odpowiedź na drugi martwy punkt opisany wyżej, bo nie zależy od tekstu polecenia.

Przed wdrożeniem czegokolwiek warto znać dwa ustawienia. permissions.disableBypassPermissionsMode: "disable" w managed settings odbiera bypass wszystkim. Użytkownik może też ustawić to sam dla siebie.

Jak ustawić uprawnienia Claude Code dla zespołu?

Proszę przejść przez to, co już mają Państwa repozytoria:

Kolejność ma znaczenie. Reguły deny nic nie kosztują i od pierwszego dnia zatrzymują najgorsze przypadki. Potem hook. Izolacja jest potrzebna dopiero wtedy, gdy coś działa bez człowieka, który patrzy.

Jak te reguły współgrają z CLAUDE.md i konwencjami zespołu, opisuje artykuł Zasady dla kodu AI w zespole. Jak pętla bez nadzoru prowadzi issue aż do pull requesta, jest w artykule Harness engineering w praktyce.

Chcą Państwo agentów, którzy są szybcy, a mimo to nie zepsują produkcji?

Reguły uprawnień, hooki, izolację i CI ustawiamy bezpośrednio w repozytoriach zespołu w ramach AI-native SDLC dla zespołów deweloperskich. Większość naszego kodu pisze AI. Senior sprawdza każdą zmianę i odpowiada za produkcję. Od 2023 roku dostarczyliśmy ponad 15 projektów produkcyjnych.

Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Dokąd zaszedłby dziś Państwa agent, gdyby nikt nie odpowiedział na żadne pytanie?

Najczęstsze pytania

Co robi --dangerously-skip-permissions w Claude Code?

Uruchamia sesję w trybie bypassPermissions, tak samo jak --permission-mode bypassPermissions. Claude Code przestaje pytać przed poleceniami, edycjami i pobieraniem. Jawne reguły ask, kilka krytycznych usunięć i narzędzia, które potrzebują człowieka, nadal pytają, a hooki nadal działają.

Czy tryb YOLO w Claude Code jest bezpieczny?

Tylko w odizolowanym środowisku. Anthropic zaleca używać bypassPermissions wyłącznie w kontenerach lub maszynach wirtualnych, gdzie Claude Code nie może wyrządzić szkód. Na laptopie programisty z prawdziwymi danymi dostępowymi proszę używać reguł uprawnień i hooków.

W jakiej kolejności są oceniane reguły allow, ask i deny?

Najpierw deny, potem ask, potem allow. Wygrywa pierwsze dopasowanie w tej kolejności, więc reguła allow nigdy nie zrobi wyjątku w regule deny, a reguła ask pyta nawet wtedy, gdy pasuje też węższa reguła allow.

Gdzie są zapisane uprawnienia Claude Code?

W plikach settings.json: managed settings dla organizacji, ~/.claude/settings.json dla jednej osoby, .claude/settings.json w repozytorium dla zespołu i .claude/settings.local.json dla lokalnych nadpisań. Managed settings wygrywają, a deny z dowolnego poziomu jest silniejszy niż allow z każdego innego.

Jak zablokować programistom tryb bypass?

Proszę ustawić permissions.disableBypassPermissionsMode na "disable", najlepiej w managed settings, gdzie nikt nie może tego nadpisać.