Claude Code i rm -rf: jak ustawić uprawnienia bash, żeby agent nie skasował projektu

Wystarczyło jedno kliknięcie w terminalu. Programista dał Claude Code szerokie uprawnienia do uruchamiania komend bash w swoim repozytorium. Asystent dostał zadanie, które wymagało kilku połączonych komend, a w jednej z nich pojawiło się rm -rf wymierzone w katalog, którego nikt nie chciał kasować. Programista odruchowo kliknął “akceptuj” i w ułamku sekundy zniknęła połowa projektu.

Ten scenariusz nie jest egzotyczny. Ryzyko ma każdy, kto pozwala Claude Code uruchamiać dowolne komendy bash, bo asystent łączy je w łańcuchy i kasuje pliki równie szybko, jak je tworzy. Pokazujemy, dlaczego to się dzieje, jakie zabezpieczenia daje sam Claude Code i jakie warstwy obrony warto dołożyć od siebie. Bardzo podobny przypadek opisaliśmy wcześniej, kiedy agent AI w Cursorze skasował produkcyjną bazę PocketOS – mechanizm błędu jest identyczny.

Dlaczego Claude Code w bashu jest niebezpieczny

Claude Code potrafi wszystko, co potrafi terminal użytkownika. Na tym polega jego największa siła i jego największy problem. Kiedy zgadzasz się na uruchamianie poleceń bash, asystent dostaje dokładnie takie same uprawnienia, jakie ty masz, gdy sam siedzisz przy klawiaturze. Może sklonować repo, zainstalować pakiety, uruchomić testy, zbudować obraz Dockera. Może też usunąć katalog, zatrzymać procesy albo nadpisać plik konfiguracyjny.

Łańcuchy komend są zdradliwe

W bashu komendy łączysz w jedną linię przez && albo ;, a agent korzysta z tego ochoczo. To wygodne dla niego, ponieważ jedno wywołanie narzędzia załatwia trzy kroki naraz. Dla użytkownika to jednak pułapka. Po pierwsze, podgląd komendy w potwierdzeniu jest długi i mało czytelny. Po drugie, oczy ślizgają się po pierwszym poleceniu, a niebezpieczne rm -rf ląduje gdzieś w środku łańcucha. Trzeci problem: przy długiej sesji klikasz “akceptuj” raz na minutę i mózg przechodzi w tryb autopilota.

Jedna szeroka zgoda na bash zamienia asystenta w współpracownika z dostępem do każdej komendy w twoim systemie.

Druga sprawa to mylenie ścieżek. Asystent czasem bierze ./node_modules zamiast ~/projects/node_modules albo wpisuje ścieżkę względną tam, gdzie powinna być bezwzględna. W rezultacie polecenie, które miało wyczyścić tymczasowy katalog w projekcie, sprząta cały folder domowy. Co gorsza, model generuje przy tym poprawne rm bez wahania, bo w treningu widział tysiące takich komend. Tyle że poprawna składnia to nie to samo co poprawna intencja.

Trzy tryby uprawnień Claude Code, które warto znać

Claude Code ma cztery tryby pracy z narzędziami. Pierwszy, domyślny, pyta o zgodę przed każdym wywołaniem narzędzia, którego nie ma na liście dozwolonych. Drugi, acceptEdits, sam akceptuje edycje plików, ale o komendy bash dalej pyta. Z kolei tryb planu pokazuje cały plan działania, zanim cokolwiek wykona, dzięki czemu widzisz, co agent zamierza zrobić. Ostatni wariant, bypassPermissions, robi wszystko bez pytania – to opcja na własne ryzyko, tylko do izolowanego środowiska.

Najwięcej projektów ginie w trybie domyślnym przy szerokiej zgodzie na bash. Dlaczego? Bo użytkownik raz zaakceptował Bash(npm:*), raz Bash(git:*), a potem pod koniec długiej sesji dorzucił uniwersalny Bash(*), bo zmęczyło go klikanie. Ten ostatni wpis otwiera drzwi do całego shella. Dlatego pierwsza zasada brzmi tak: nigdy nie dodawaj Bash(*) do listy dozwolonych, choćby agent bardzo prosił. Zamiast tego ustaw allowlistę osobno dla każdej komendy, którą faktycznie chcesz mu pozwolić uruchamiać. Sposób opisujemy w następnej sekcji.

Allowlist i denylist – co warto zablokować

Claude Code czyta uprawnienia z pliku .claude/settings.local.json w katalogu projektu albo z ustawień globalnych w ~/.claude/settings.json. Format jest prosty. Dwie listy – allow i deny. Każda zawiera wzorce dopasowane do narzędzia i argumentów.

Allowlist konkretny, nie ogólny

Zamiast Bash(*) wpisz konkretne komendy zawężone do potrzebnego prefiksu. Na przykład Bash(npm test:*) pozwala uruchamiać testy w różnych wariantach, ale blokuje instalację pakietów. Z kolei Bash(git status:*) zezwoli na sprawdzenie statusu, jednak nie przepuści git push --force. Taka rozbudowana lista wygląda upierdliwie, kiedy ją ustawiasz, ale w zamian oszczędza godziny stresu po pierwszej kasacji.

Denylist twardych zakazów

Druga warstwa to denylist. Tu wpisujesz wzorce, których agent nigdy nie wykona, nawet jeśli przypadkowo trafią na allowlist. Sensowny zestaw startowy obejmuje: Bash(rm -rf:*), Bash(rm -fr:*), Bash(sudo:*), Bash(chmod 777:*), Bash(mkfs:*), Bash(dd:*). W rezultacie przy każdej próbie wykonania takiej komendy agent dostaje twardą odmowę, niezależnie od tego, czy zgadzasz się odruchowo, czy nie.

Denylist nie jest paranoją. To podstawa higieny pracy z agentem, który ma terminal pod ręką.

Co więcej, ustawienia możesz mieć osobne dla każdego projektu. Repo z produkcyjnym kodem dostaje wąską allowlistę i szeroką denylistę, a repo z eksperymentem na pustym katalogu może być bardziej liberalne. To trochę jak z pasami w samochodzie. Możesz ich nie zapinać tylko na osiedlu, ale na autostradzie wolisz mieć je zapięte.

Hooki PreToolUse – ostatnia bramka przed wykonaniem

Hooki to mechanizm Claude Code, który uruchamia twój własny skrypt przed albo po wywołaniu narzędzia. PreToolUse odpala się, zanim asystent wykona komendę, co daje ci ostatnią szansę na zatrzymanie destrukcyjnej operacji. Jeśli skrypt zwróci kod wyjścia różny od zera, narzędzie nie wystartuje. Jeśli zwróci zero, idzie dalej.

Prosty hook w Pythonie albo w bashu czyta argumenty komendy z wejścia i sprawdza, czy nie ma w niej rm -rf na ścieżce poza katalogiem projektu. Jeśli tak, hook blokuje wykonanie. Do tego samego mechanizmu możesz dopisać zakaz git push --force na gałęzi main, twardą blokadę dd albo walidację, że agent nie kasuje plików spoza repo. Hooków agent nie obejdzie żadną perswazją, bo uruchamia je sama warstwa narzędzi Claude Code, zanim model dostanie głos.

Allowlist można przekliknąć przez nieuwagę. Hook to skrypt, który przekliknięcia nie ma.

Sam Anthropic przy okazji niedawnego postmortemu Claude Code zachęcał użytkowników, żeby korzystali z hooków odważniej. To dobra wskazówka, ponieważ Anthropic widzi w swoich logach każdą historię, która zaczyna się od “model wykonał coś, czego nie powinien”.

Worktrees i git jako ostatnia warstwa obrony

Nawet z dobrymi uprawnieniami i hookami warto pracować z agentem na izolowanym worktree. Git worktree pozwala mieć drugą kopię repo w osobnym katalogu, podpiętą do innego brancha. Claude Code uruchomiony na worktree kasuje pliki tylko w tej kopii, a głównego brancha nie dotyka. Mateusz korzysta z tego mechanizmu na co dzień przy eksperymentalnych sesjach z agentem.

Drugi prosty zwyczaj to commit przed każdym uruchomieniem agenta. Nawet jeśli kod jest w trakcie pisania i niczego nie kompiluje, commitujesz roboczy stan z wiadomością wip: przed sesją z agentem. W rezultacie po katastrofie wystarczy git reset --hard HEAD i wracasz do punktu startu. To minutowa inwestycja, która zwraca się przy pierwszym rm -rf.

Kurs n8n 2.0 · Kodożercy

Automatyzacja to dziś jedna z najbardziej poszukiwanych umiejętności

Firmy szukają ludzi, którzy łączą procesy z narzędziami. Kurs n8n 2.0 na Kodożercach da Ci praktyczne umiejętności (webhooki, API, automatyczne przepływy danych), które możesz pokazać już jutro.

Zobacz program kursu →

Co zrobić, jeśli już ci skasował projekt

Pierwsza odpowiedź brzmi: nie panikuj. Jeśli pliki trafiły do repozytorium i były scommitowane, sprawdź git reflog. Reflog trzyma historię wszystkich ruchów HEAD, także tych, których git log już nie pokazuje. W większości przypadków znajdziesz tam ostatni dobry stan i wrócisz do niego komendą git reset --hard <hash>. To działa nawet po git reset --hard HEAD, dopóki nie uruchomiłeś git gc.

Jeśli pliki nie były scommitowane, ale otwierałeś je w edytorze, ratuje cię historia VS Code albo IntelliJ. Oba edytory trzymają własną historię zmian, niezależnie od gita. W VS Code zaglądasz do Timeline w widoku eksploratora, a w IntelliJ klikasz “Local History” w menu kontekstowym pliku. To często ostatnia deska ratunku dla plików, które nigdy nie trafiły do gita.

Najgorszy scenariusz to pliki, których ani nie scommitowałeś, ani nie otwierałeś w edytorze. Tu zostaje narzędzie typu extundelete na ext4 albo photorec na innych systemach plików. Skuteczność zależy od tego, czy system zdążył nadpisać sektory, na których leżały pliki. Dlatego najlepsza obrona przed rm -rf w Claude Code zaczyna się minutę przed sesją, a nie minutę po niej.

Podsumowanie

Claude Code skasuje projekt tylko wtedy, kiedy mu na to pozwolisz. Robisz to dwa razy: raz, kiedy dajesz mu szeroką zgodę na bash, a drugi raz, kiedy odruchowo klikasz potwierdzenie. Obie ścieżki zamykasz w piętnaście minut konfiguracji. Wąska allowlista konkretnych komend, denylista twardych zakazów, hooki PreToolUse na destrukcyjne polecenia, worktree na eksperymenty i commit przed każdą sesją. Cztery warstwy, każda zatrzymuje inny rodzaj błędu.

Jeśli masz zrobić tylko jedną rzecz, zrób tę. Wpisz Bash(rm -rf:*) do denylisty już teraz. To jedna linia w .claude/settings.local.json, która nic cię nie kosztuje, a potrafi uratować przed katastrofą, do której nigdy nie powinno dojść.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.