Blog JSystems - uwalniamy wiedzę!

Szukaj

Claude Code

Jak skonfigurować allow i deny w settings.json Claude Code

W skrócie

  • Chcesz precyzyjnie ustawić, co Claude Code może robić bez pytania, a czego mu wprost zabronić.
  • Służą do tego listy allow, deny i ask w pliku settings.json, z regułami dla konkretnych narzędzi.
  • Rozwiązanie: naucz się składni reguł (np. Bash(git push:*)), rozłóż konfigurację na poziom globalny, projektowy i lokalny oraz pamiętaj, że deny ma pierwszeństwo.

Model uprawnień to serce bezpiecznej pracy z Claude Code, narzędziem CLI od Anthropic. Zamiast zgadywać przy każdym monicie, warto raz porządnie skonfigurować, które operacje są dozwolone automatycznie, o które narzędzie ma zawsze pytać, a które są całkowicie zablokowane. Wszystko dzieje się w pliku settings.json i opiera na trzech listach. Dobrze dobrane reguły dają jednocześnie płynność (bez zbędnych pytań) i bezpieczeństwo (żadnych przypadkowych operacji na produkcji). Ten temat dotyczy każdego, kto używa Claude Code w realnym projekcie, a nie tylko do zabawy.

Jak to wygląda w praktyce

Bez konfiguracji Claude Code albo pyta o wszystko, albo - jeśli komuś ktoś włączył zbyt szeroki tryb - wykonuje operacje, których wolałbyś nie widzieć bez potwierdzenia. Docelowo chcesz mieć plik z trzema jasnymi listami. Oto realny przykład kompletnej konfiguracji projektowej:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Edit(src/**)"
    ],
    "ask": [
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(.env)",
      "Read(secrets/**)"
    ]
  }
}

Taki plik mówi wprost: testy i podgląd zmian bez pytania, git push zawsze z potwierdzeniem, a kasowanie rekurencyjne i odczyt sekretów całkowicie zablokowane.

Dlaczego Claude Code tak działa

Każde działanie agenta jest przypisane do konkretnego narzędzia: Bash (komendy powłoki), Edit i Write (zmiana plików), Read (odczyt), WebFetch (pobieranie z sieci) czy narzędzia MCP. Reguła to nazwa narzędzia z opcjonalnym wzorcem w nawiasie. Gdy agent chce coś zrobić, Claude Code sprawdza reguły w ustalonej kolejności: najpierw deny (jeśli pasuje - odmowa, koniec), potem allow (jeśli pasuje - wykonaj bez pytania), a jeśli nic nie pasuje, wpada w ask lub domyślne pytanie. Dlatego deny zawsze wygrywa - to celowe, żeby dało się bezpiecznie zablokować coś, co szersza reguła allow mogłaby przepuścić.

Jak to rozwiązać krok po kroku

  1. Otwórz konfigurację uprawnień - najwygodniej komendą /permissions w sesji albo edytując plik .claude/settings.json ręcznie.
  2. Do listy allow dodaj operacje powtarzalne i bezpieczne: uruchamianie testów, lintowanie, podgląd gita, edycję plików w katalogu źródłowym. Wzorzec Edit(src/**) pozwala na edycję wszystkiego w src.
  3. Do listy ask wrzuć operacje wrażliwe, które chcesz nadzorować za każdym razem - klasykiem jest Bash(git push:*), żeby nic nie trafiło do zdalnego repozytorium bez Twojej wiedzy.
  4. Do listy deny wpisz to, czego agent nie ma prawa dotknąć nigdy: kasowanie rekurencyjne, odczyt plików z sekretami, dostęp do katalogów produkcyjnych.
  5. Poznaj składnię wzorców: dokładne dopasowanie to Bash(git status), prefiks z dowolnym dalszym ciągiem to Bash(npm run test:*), a wzorce plików używają glob, np. Read(secrets/**).
  6. Rozłóż konfigurację na poziomy: reguły wspólne dla wszystkich projektów trzymaj w ~/.claude/settings.json, reguły zespołowe w wersjonowanym .claude/settings.json, a prywatne wyjątki w .claude/settings.local.json (dopisz ten plik do .gitignore).
  7. Po zapisaniu zrestartuj sesję lub uruchom /permissions, aby narzędzie wczytało nowe reguły.

Jak sprawdzić, że zadziałało

Wywołaj /permissions - lista powinna pokazać dokładnie te reguły, które zapisałeś, z rozbiciem na allow, ask i deny. Przetestuj każdą listę osobno: poproś o operację z allow (ma się wykonać bez pytania), o operację z ask (ma pojawić się monit) i o operację z deny (ma zostać odmówiona, a agent poinformuje, że reguła to blokuje). Jeśli wszystkie trzy zachowują się zgodnie z konfiguracją, model uprawnień działa poprawnie.

Wróć do listy: 100 najczęstszych problemów z Claude Code

Szkolenie Claude Code - od zera do zespołu agentów AI, prowadzi Łukasz Matuszewski (JSystems)

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

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

Tryb planowania, tryby uprawnień, komendy, MCP, hooki i systemy multi-agent - wszystko na żywym kodzie podczas trzydniowego szkolenia. Prowadzi Łukasz Matuszewski. Szkolenie ma terminy gwarantowane - odbędzie się niezależnie od liczby zgłoszeń.

Sprawdź szkolenie Claude Code

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Najczęściej zadawane pytania

Która lista ma pierwszeństwo, gdy reguły allow i deny się nakładają?
Lista deny ma zawsze pierwszeństwo nad allow. Claude Code sprawdza reguły w kolejności: najpierw deny (jeśli pasuje, odmawia i kończy), potem allow (jeśli pasuje, wykonuje bez pytania), a jeśli nic nie pasuje, przechodzi do ask lub domyślnego pytania. Dzięki temu można bezpiecznie zablokować coś, co szersza reguła allow mogłaby przepuścić.
Jak wygląda składnia reguł uprawnień w settings.json?
Reguła to nazwa narzędzia z opcjonalnym wzorcem w nawiasie. Dokładne dopasowanie to Bash(git status), prefiks z dowolnym dalszym ciągiem to Bash(npm run test:*), gdzie gwiazdka po dwukropku dopasowuje resztę polecenia. Wzorce plików używają glob, na przykład Read(secrets/**) obejmuje wszystko w katalogu secrets.
Do czego służy lista ask w uprawnieniach Claude Code?
Lista ask wymusza pytanie o zgodę za każdym razem przy danej operacji, nawet jeśli byłaby powtarzalna. Wrzuca się na nią operacje wrażliwe, które chcesz nadzorować - klasyką jest Bash(git push:*), żeby nic nie trafiło do zdalnego repozytorium bez Twojej świadomej akceptacji przy każdym wypchnięciu.
Jak rozłożyć konfigurację uprawnień między różne poziomy?
Reguły wspólne dla wszystkich projektów trzymaj w ~/.claude/settings.json, reguły zespołowe w wersjonowanym .claude/settings.json (współdzielonym przez repozytorium), a prywatne wyjątki w .claude/settings.local.json, który dopisujesz do .gitignore. Taki podział pozwala mieć wspólny standard zespołu i osobiste ustawienia bez konfliktów.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...