rm -rf od roota — co może zrobić Claude Code gdy ma za dużo uprawnień

Październik 2025. Mike Wolak uruchamia Claude Code na Ubuntu działającym przez WSL2. Sesja idzie normalnie — zadanie dotyczące projektu, kilka edycji plików, standardowa praca. W pewnym momencie Claude Code wykonuje rm -rf od katalogu root (/). Pliki są stracone.

Gdyby to była historia o użytkowniku, który bezmyślnie podał flagę --dangerously-skip-permissions, byłaby pouczająca, ale prosta. Problem w tym, że Wolak tej flagi nie używał. Zawiódł sam system uprawnień.

Co się wydarzyło (GitHub issue #10077)

Wolak zgłosił incydent jako issue #10077 na GitHubie Claude Code w październiku 2025. Opis był precyzyjny: brak flagi dangerously-skip-permissions, standardowa sesja, polecenie rm -rf wydane od poziomu katalogu root na systemie Ubuntu/WSL2.

Mechanizm nie był do końca jasny nawet po dyskusji pod issue’em. Możliwe kombinacje: zadanie polegające na czyszczeniu tymczasowych plików + zbyt szeroko zdefiniowany scope + Claude interpretujący root jako punkt startowy zamiast jako ograniczenie. Ale szczegóły są tu mniej ważne niż wniosek ogólny: Claude Code może wyrządzić poważną szkodę nawet bez explicite wyłączonego systemu uprawnień, jeśli uruchamiasz go z konta z prawami roota lub z szerokimi uprawnieniami systemowymi.

Czym jest —dangerously-skip-permissions i dlaczego istnieje

Flaga --dangerously-skip-permissions wyłącza interaktywne pytania o zgodę na operacje plikowe i systemowe. Normalnie Claude Code pyta przed każdą potencjalnie destruktywną akcją. Ta flaga kasuje te pytania — Claude działa automatycznie, bez pauz.

Flaga istnieje z konkretnego powodu: pipelines CI/CD, automatyzacje skryptowe, środowiska gdzie interaktywne zatwierdzanie jest niemożliwe. To legalne zastosowanie — ale wyłącznie w środowiskach izolowanych, gdzie nawet najgorszy scenariusz nie dosięga plików, na których zależy.

Problem polega na tym, że część użytkowników używa jej na swojej maszynie roboczej, żeby nie klikać “approve” co chwilę. To skrót, który zamienia drobną uciążliwość w realne ryzyko.

Uruchamiaj w kontenerze, nie na swojej maszynie

To nie jest opcja tylko dla zaawansowanych — to podstawa bezpieczeństwa przy bardziej autonomicznych sesjach Claude Code.

Uruchomienie Claude Code w kontenerze Docker z ograniczonym montowaniem katalogów sprawia, że nawet rm -rf / nie dosięga Twoich plików — Claude widzi tylko to, co mu pokazałeś. Przykładowa konfiguracja startowa:

docker run -it --rm \
  -v $(pwd)/projekt:/workspace \
  -w /workspace \
  node:20 bash

Claude Code widzi tylko katalog projekt. Reszta systemu jest niewidoczna.

Trzy rzeczy do zapamiętania

Po pierwsze: --dangerously-skip-permissions to narzędzie dla środowisk izolowanych, nie skrót na własnej maszynie. Jeśli go używasz, powinieneś wiedzieć co to kontener i działać wewnątrz niego.

Po drugie: incydent Wolaka pokazuje, że nawet bez tej flagi Claude Code może wyrządzić szkodę jeśli ma szerokie uprawnienia na poziomie systemu. Nie uruchamiaj Claude Code z konta root ani jako administrator systemu.

Po trzecie: zgoda na każde pytanie to nie gwarancja bezpieczeństwa. Czytaj co zatwierdzasz. Przy sesjach angażujących operacje na plikach poza projektem — zatrzymaj się na chwilę. Ślepe klikanie “approve” to oddzielny temat (approval fatigue), ale zaczyna się właśnie tutaj.

Co Anthropic zrobił po issue #10077

Issue Wolaka spowodował dyskusję w zespole Claude Code o domyślnych ograniczeniach przy operacjach rekurencyjnych na katalogach systemowych. Późniejsze wersje dodały dodatkowe sprawdzenia dla operacji mogących objąć / lub ścieżki poza katalogiem roboczym sesji.

To niejedyna zmiana bezpieczeństwa wynikająca ze zgłoszeń społeczności — model uprawnień w Claude Code ewoluuje, m.in. w kierunku auto mode (automatyczny klasyfikator zamiast pełnego wyłączenia uprawnień). Ale żadna zmiana od strony Anthropic nie zastąpi uruchamiania agenta w izolowanym środowisku, gdy robisz coś więcej niż edycja plików w jednym projekcie.