Uprawnienia per projekt vs globalne w Claude Code - gdzie co ustawić

Claude Code

Uprawnienia per projekt vs globalne w Claude Code - gdzie co ustawić

W skrócie

W Claude Code, narzędziu CLI od Anthropic do programowania z AI, sam decydujesz, których operacji narzędzie może użyć bez pytania o zgodę. Tę decyzję zapisujesz w pliku ustawień - i tu zaczyna się zamieszanie, bo takich plików jest kilka, na różnych poziomach. Jedno miejsce działa we wszystkich projektach, inne tylko w bieżącym, a jeszcze inne jest prywatne i nie trafia do repozytorium. Jeśli wrzucisz regułę nie tam, gdzie trzeba, albo zadziała ona za szeroko, albo w ogóle jej nie zobaczysz. Poniżej porządkujemy, gdzie co ustawić.

Jak to wygląda w praktyce

Dajesz Claude Code zgodę na uruchamianie testów, a przy następnym projekcie narzędzie znów pyta o to samo - bo zgodę zapisałeś lokalnie w tamtym repozytorium. Albo odwrotnie: dodajesz regułę globalnie, a potem dziwisz się, że w prywatnym projekcie narzędzie samo odpala komendy, na które nie chciałeś się zgadzać wszędzie. Bywa też, że zespół commituje wspólne reguły do repozytorium, a Twoja osobista zgoda - której nie chcesz nikomu narzucać - ląduje w tym samym pliku i przez pomyłkę idzie do gita. W efekcie nie wiesz, która reguła skąd pochodzi i dlaczego akurat teraz zadziałała.

Dlaczego Claude Code tak działa

Claude Code nie ma jednego pliku ustawień - ma ich kilka, ułożonych w warstwy o rosnącej ważności. Od najmniej do najbardziej znaczącej są to: ustawienia użytkownika w ~/.claude/settings.json (globalne, dla wszystkich Twoich projektów), ustawienia projektu w .claude/settings.json (wspólne dla zespołu, commitowane do repozytorium), ustawienia lokalne w .claude/settings.local.json (Twoje prywatne w danym projekcie, poza gitem), to, co przekazujesz flagą --settings, i na samej górze ustawienia zarządzane przez organizację. Narzędzie czyta wszystkie i scala je - gdy reguły się kłócą, wygrywa ta z wyższej warstwy. Jest przy tym jedna nadrzędna zasada bezpieczeństwa: reguła odmowy (deny) zawsze bije regułę zgody (allow), niezależnie od warstwy. Dzięki temu blokada raz nałożona nie da się przypadkiem obejść zgodą z niższego poziomu.

Jak to rozwiązać krok po kroku

1. Zdecyduj o zasięgu reguły, zanim ją zapiszesz. Zadaj sobie pytanie: ma działać we wszystkich moich projektach, tylko w tym repozytorium dla całego zespołu, czy tylko u mnie i bez śladu w gicie.
2. Reguły, które chcesz mieć wszędzie, wpisz do ~/.claude/settings.json w katalogu domowym. To dobre miejsce na uniwersalne zgody, na przykład na czytanie plików narzędziami Read, Grep i Glob.
3. Reguły wspólne dla projektu i zespołu wpisz do .claude/settings.json w katalogu repozytorium i zacommituj. Tu trzymaj to, co ma obowiązywać każdego, kto pracuje nad kodem - zarówno zgody, jak i blokady.
4. Reguły prywatne, których nie chcesz nikomu narzucać, wpisz do .claude/settings.local.json. Ten plik jest przeznaczony dla Ciebie i domyślnie pomijany przez gita, więc Twoje osobiste zgody nie trafią do repozytorium.
5. Ustawienia zapisuj w bloku permissions z listami allow, ask i deny. Na liście deny umieszczaj to, czego narzędzie nigdy nie ma robić - pamiętając, że ta lista jest silniejsza niż jakakolwiek zgoda.
6. Gdy chcesz jednorazowo przesłonić wszystko z linii poleceń, użyj flagi --settings ze wskazaniem własnego pliku. Ma ona wyższą ważność niż pliki projektu i użytkownika, więc nadaje się do doraźnych uruchomień.
7. Do przeglądania i edycji reguł w trakcie sesji użyj polecenia /permissions - pokaże, co jest aktualnie dozwolone, i pozwoli dopisać nową regułę bez ręcznego grzebania w plikach.

Jak sprawdzić, że zadziałało

Otwórz w sesji /permissions i sprawdź, czy Twoja reguła jest na liście oraz z jakiej warstwy pochodzi. Najprostszy test praktyczny: poproś Claude Code o operację, którą właśnie dozwoliłeś - jeśli wykonuje ją bez pytania, zgoda z odpowiedniego pliku zadziałała. Przełącz się do innego projektu i powtórz: reguła z .claude/settings.local.json nie powinna tam obowiązywać, a reguła z ~/.claude/settings.json - owszem. Na koniec upewnij się, że plik z prywatnymi zgodami nie wchodzi do repozytorium: git status nie powinien pokazywać .claude/settings.local.json jako pliku do zacommitowania.

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

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