SSD Nodes Learn
Przewodniki Matt ConnorAutor: Matt Connor · Zaktualizowano 2026-07-24

Jak bezpiecznie uruchomić Claude Code

Analiza ryzyka przy użyciu flagi skip permissions. Dowiedz się, jak izolować Claude Code poprzez sandbox, kontenery oraz tymczasowe instancje VPS.

Co oznacza bezpieczne uruchamianie Claude Code na serwerze

Aby bezpiecznie uruchomić Claude Code na serwerze, należy pozostawić włączone komunikaty o uprawnieniach, uruchamiać program jako dedykowanego użytkownika o ograniczonych uprawnieniach oraz zapewnić procesom działającym bez nadzoru rzeczywiste ograniczenia zamiast polegania na zaufaniu: wbudowaną piaskownicę (sandbox), kontener lub tymczasowy VPS, który nie zawiera żadnych istotnych danych. Flaga --dangerously-skip-permissions usuwa etap zatwierdzania działań między modelem a powłoką (shell). Taki kompromis może być uzasadniony przy pracy bez nadzoru, ale tylko wewnątrz bariery ograniczającej skutki błędnej komendy. Ten przewodnik wyjaśnia, co faktycznie zmienia ta flaga oraz jak budować taką barierę za pomocą stopniowej izolacji.

Co Claude Code może zrobić na Twoim systemie

Claude Code to agent programistyczny działający w terminalu. Odczytuje pliki, zapisuje pliki i wykonuje komendy powłoki jako użytkownik, który go uruchomił. To stanowi główną wartość narzędzia: może sklonować repozytorium, edytować kod, uruchomić testy, odczytać błędy i naprawiać kod w pętli, bez konieczności ręcznego wpisywania każdej komendy. Jeśli nie skonfigurowano jeszcze narzędzia na serwerze, instrukcja uruchamiania Claude Code na VPS z tmux opisuje instalację i obsługę sesji. Ta strona opisuje uprawnienia, które przekazuje się agentowi po jego uruchomieniu.

Ryzyko jest to samo, co w przypadku powtórzenia tego samego zdania. Proces wykonujący komendy powłoki jako dany użytkownik może wykonać wszystko, co może ten użytkownik. Może odczytać ~/.ssh/id_ed25519, ~/.aws/credentials oraz każdy plik .env, który użytkownik może otworzyć. Może uruchomić curl i wysłać dane do dowolnego hosta, z którym serwer może nawiązać połączenie. Może uruchomić git push --force. Agent nie posiada własnych motywów. Zagrożeniem jest błąd w zadaniu lub tekst odczytany podczas pracy, który zawiera instrukcje napisane przez kogoś innego: stronę internetową, którą pobrano, lub komentarz w zgłoszeniu (issue), które agent miał naprawić. Ten drugi przypadek nazywa się prompt injection i to dlatego stwierdzenie „model jest zazwyczaj rozsądny” nie stanowi planu bezpieczeństwa. Należy planować pod kątem błędnego wykonania zadania, a nie pod kątem scenariusza typowego.

System uprawnień w prostych słowach

Domyślnie Claude Code prosi o zgodę przed podjęciem działania. Odczytywanie plików wewnątrz projektu odbywa się po cichu, ale edycja pliku lub uruchomienie komendy powłoki najpierw wyświetla dokładną edycję lub komendę i oczekuje na potwierdzenie. Można zatwierdzić pojedynczą akcję lub zatwierdzić tego typu akcje na całą sesję. Zatwierdzenia te obowiązują tylko w ramach sesji: zamknięcie CLI sprawia, że kolejna sesja zaczyna się z zachowaniem ostrożności. Dla reguł, które mają być stałe, plik konfiguracyjny przechowuje listy zezwoleń (allow), pytań (ask) i zakazów (deny). Na przykład: zezwól na git status, pytaj o git push, zabroń odczytu .env. Reguły typu deny mają zawsze pierwszeństwo.

Projekt ten zakłada, że człowiek monitoruje terminal, co ma miejsce w przypadku laptopa. Na serwerze problemem jest często brak nadzoru. Użytkownik uruchamia długie zadanie w tmux i idzie spać, a agent, który zatrzymuje się, aby zadać pytanie o 2:00 nad ranem, nie robi żadnych postępów aż do rana. Pauza generuje koszty czasowe oraz finansowe, ponieważ sesja Claude Code w stanie bezczynności traci ciepły cache promptu, a kolejny cykl wymaga ponownego jego odbudowania. To jest rzeczywisty powód, dla którego na serwerach sięga się po flagę pomijania (skip flag), a problem, który ona rozwiązuje, jest realny. Reszta tego przewodnika dotyczy rozwiązania tego problemu bez rezygnacji ze wszystkich zabezpieczeń.

Co zmienia flaga --dangerously-skip-permissions

claude --dangerously-skip-permissions wyłącza etap zatwierdzania. Edycje odbywają się bez pytania. Komendy powłoki są uruchamiane bez pytania. Sprawdzanie chronionych ścieżek (protected-path checks), które normalnie zabezpieczają wrażliwe lokalizacje, również jest pomijane. Twoje jawne reguły deny nadal obowiązują, a kilka ekstremalnych akcji nadal wymaga potwierdzenia, ale ogólne podsumowanie jest proste: wszystko, co model zdecyduje się uruchomić, zostanie uruchomione.

Na serwerze istotne są dwa fakty dotyczące tej flagi. Po pierwsze, flaga jest blokowana, gdy Claude Code działa jako root lub pod sudo na systemach Linux i macOS, ponieważ root bez komunikatów o zgodzie może zmienić dowolny plik lub usługę na maszynie. Agent i tak wymaga własnego, nieuprzywilejowanego konta, a flaga wymusza to rozwiązanie. Po drugie, flaga nie zmienia zachowania modelu w żaden sposób. Usuwa ona człowieka z pętli decyzyjnej i nie zmienia niczego innego, więc każdy błąd, który zostałby wychwycony przez prompt, zostanie teraz wykonany.

Oto rzetelna analiza. Jeśli pomijasz uprawnienia, pytanie o bezpieczeństwo zmienia się z „czy agent zrobi coś złego” na „jak duże szkody może wyrządzić jedna błędna akcja”. Przestajesz próbować kontrolować każdą decyzję, a zaczynasz kontrolować promień rażenia (blast radius). Rozwiązaniem jest izolacja, która realizowana jest stopniowo.

Wbudowana piaskownica Claude Code

Zanim przejdziemy do stopni izolacji, należy wiedzieć, że Claude Code dostarcza obecnie piaskownicę na poziomie systemu operacyjnego dla uruchamianych komend, co eliminuje większość powodów, dla których użytkownicy sięgali po flagę skip. Na systemie Linux używa ona bubblewrap do izolacji systemu plików oraz socat do przekierowania ruchu sieciowego przez proxy. Wewnątrz piaskownicy komenda może zapisywać dane tylko w katalogu projektu oraz w tymczasowym katalogu sesji, a dostęp do sieci może uzyskać tylko przez proxy, które sprawdza każdą domenę na liście zezwoleń. Gdy komenda po raz pierwszy próbuje połączyć się z nową domeną, Claude Code prosi o zgodę.

Włącz funkcję za pomocą komendy /sandbox wewnątrz sesji. W systemach Ubuntu i Debian należy najpierw zainstalować dwa wymagane pakiety:

sudo apt install bubblewrap socat

W systemach Ubuntu 24.04 i nowszych domyślna polityka AppArmor blokuje narzędziu bubblewrap możliwość tworzenia wymaganych przestrzeni nazw użytkownika (user namespaces). Panel piaskownicy informuje, gdy brakuje wymaganych komponentów, a dokumentacja sandboxing Claude Code zawiera krótki profil AppArmor, który rozwiązuje ten problem.

Piaskownica posiada tryb auto-allow: komendy w piaskownicy działają bez żadnych komunikatów, ponieważ wymuszona bariera wykonuje pracę, którą wcześniej wykonywały komunikaty o zgodzie. Komendy, których nie można uruchomić w piaskownicy, przechodzą do standardowego przepływu uprawnień, więc nietypowe akcje nadal wymagają potwierdzenia. Dla większości procesów serwerowych jest to właściwa alternatywa dla flagi skip, ponieważ zamiast braku zabezpieczeń otrzymuje się znacznie mniej pytań dzięki barierze wymuszonej przez system operacyjny.

Należy pamiętać o jej ograniczeniach. Domyślnie komenda w piaskownicy nadal może odczytać większość systemu plików, w tym pliki z poświadczeniami, chyba że zabroni się dostępu do tych ścieżek; ustawienie sandbox.credentials służy właśnie temu. Proxy sieciowe sprawdza nazwy domen, ale nie inspekcjonuje samego ruchu, więc szerokie zezwolenie, takie jak github.com, nadal umożliwia wyprowadzenie danych. Docker nie działa wewnątrz piaskownicy. Piaskownica znacząco podnosi poziom bezpieczeństwa, ale nie stanowi pełnej bariery izolacji, dlatego poniższe stopnie izolacji nadal mają znaczenie.

Drabina izolacji

Trzy stopnie, w rosnącej kolejności izolacji. Należy wybrać najniższy stopień, który odpowiada pozostałym usługom działającym na maszynie.

Stopień 1: dedykowany nieuprzywilejowany użytkownik. Agent otrzymuje własne konto, własny katalog domowy, własny katalog projektu i nie posiada uprawnień sudo:

sudo adduser --disabled-password --gecos "" agent

Granica konta uniemożliwia agentowi dostęp do Twoich plików: Twoich kluczy SSH oraz wszystkich innych projektów na maszynie. Dzięki temu flaga skip staje się użyteczna, ponieważ flaga ta odmawia uruchomienia jako root. Jest to ta sama zasada, co uruchamianie każdej usługi jako nieuprzywilejowany użytkownik, zastosowana do agenta. Stopień 1 nie ogranicza sieci ani niczego na maszynie, co jest ogólnodostępne (world-readable).

Stopień 2: kontener. Anthropic publikuje referencyjny devcontainer, który uruchamia Claude Code jako użytkownik niebędący rootem, z regułami firewall ograniczającymi hosty, do których agent może dotrzeć; własny kontener spełnia to samo zadanie. System plików zostaje ograniczony do zamontowanych wolumenów, a wyjście sieciowe do zakresu dozwolonego przez reguły kontenera. Jest to odpowiedni środkowy stopień izolacji, gdy serwer hostuje inne istotne usługi. Ograniczeniem jest fakt, że kontenery współdzielą jądro systemu hosta, a jeden błąd przy montowaniu znosi barierę; przekazanie kontenerowi /var/run/docker.sock pozwala mu uzyskać dostęp do całego hosta.

Stopień 3: dedykowany VPS. Najsilniejszy stopień jest najbardziej radykalny: należy zapewnić agentowi całą maszynę, która nie zawiera niczego istotnego. Mały VPS kosztuje kilka dolarów miesięcznie. Należy go skonfigurować zgodnie z instrukcją pierwszej dziesięciu minut na nowym VPS, wykonać migawkę (snapshot) czystego stanu i pozwolić agentowi pracować. Nic innego nie znajduje się na tej maszynie. Żadnych prywatnych kluczy SSH, tylko klucz wdrożeniowy (deploy key) ograniczony do jednego repozytorium. Żadnych poświadczeń chmurowych, żadnych danych produkcyjnych. Gdy proces przebiegnie nieprawidłowo lub gdy wymagany będzie czysty start, należy przywrócić migawkę lub zniszczyć i odbudować maszynę w kilka minut. Kosztem jest czynsz za serwer. W tym modelu --dangerously-skip-permissions przestaje być niebezpieczne, ponieważ najgorszym realistycznym skutkiem jest odbudowa serwera i unieważnienie jednego tokenu.

Stopnie te się kumulują. Agent w piaskownicy, uruchamiany jako użytkownik nieuprzywilejowany na tymczasowym VPS, kosztuje prawie nic dodatkowo i sprawia, że historie awarii stają się nieistotne. Brak incydentów jest celem.

Ochrona poświadczeń

Zasada, która rekompensuje wszystkie inne: użytkownik agenta nie może mieć możliwości odczytu sekretów należących do innych procesów.

Klucz API należy przekazać wyłącznie agentowi. Należy umieścić go w pliku należącym do użytkownika agenta z uprawnieniami 600 i załadować podczas startu powłoki:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Następnie należy zabezpieczyć drugą stronę. W systemach Debian i Ubuntu katalogi domowe są często tworzone jako czytelne dla każdego użytkownika na maszynie, dlatego należy je uszczelnić: chmod 750 /home/youruser. Należy sprawdzić to za pomocą ls -ld /home/* i naprawić wszystko, co konto agenta może wymienić.

Należy ograniczać zakres każdego tokenu. Drobnoziarnisty token GitHub ograniczony do jednego repozytorium lub klucz wdrożeniowy na jedno repozytorium oznacza, że wyciek poświadczeń dotyczy tylko jednego projektu, a nie całego konta. Jeśli używa się piaskownicy, należy dodać jej ustawienia poświadczeń, aby ~/.ssh i ~/.aws były zabronione nawet w trybie odczytu. Należy również całkowicie trzymać poświadczenia produkcyjne poza maszyną, ponieważ agent nie może wyciec sekretu, którego nigdy tam nie było.

Git jako siatka bezpieczeństwa

Każda zmiana wprowadzona przez agenta powinna być możliwa do zweryfikowania i wycofania, a git zapewnia obie te funkcje bezpłatnie, jeśli agent pracuje na gałęzi (branch):

git switch -c agent/refactor-auth

Po zakończeniu pracy należy zweryfikować przebieg za pomocą git diff main...agent/refactor-auth, zatwierdzić poprawne zmiany i usunąć gałąź, jeśli praca nie przyniosła efektów. Należy zabezpieczyć główną gałąź (main branch) po stronie platformy (forge), aby token agenta nie mógł wysyłać do niej zmian (push) ani wymuszać ich (force-push) gdziekolwiek. Historia commitów pełni funkcję logu audytowego zdarzeń, które miały miejsce podczas braku nadzoru, co jest warte więcej niż jakakolwiek historia terminala.

Sieć jako element promienia rażenia

Agent może uruchomić curl. To zdanie definiuje cały problem wycieku danych: wszystko, co agent może odczytać, może również wysłać w inne miejsce, a agent poddany prompt injection może to zrobić. Zwykły użytkownik nie ogranicza tego w żaden sposób, ponieważ każdy użytkownik może połączyć się z każdym hostem, z którym może połączyć się serwer. Piaskownica ogranicza to poprzez proxy na poziomie domeny. Kontener może to ograniczyć za pomocą własnych reguł firewall. Dedykowany VPS ogranicza to, co w ogóle można wyciec, co jest najskuteczniejszą odpowiedzią spośród trzech.

Nie należy próbować rozwiązywać problemu wyjścia sieciowego za pomocą samego ufw. ufw domyślnie zezwala na cały ruch wychodzący, a tworzenie reguł wychodzących, które nadal umożliwiają działanie apt, npm, git i API Claude, jest żmudną pracą, która może po cichu przestać działać. Zamiast tego należy wybrać barierę na poziomie piaskownicy, kontenera lub maszyny, gdzie lista zezwolenia dla domen lub czysta maszyna wykonują to samo zadanie w sposób przejrzysty.

Jeśli buduje się własnego agenta bezpośrednio przez API, a nie uruchamia Claude Code, te same zasady mają zastosowanie. Instrukcja Budowanie agenta AI z Claude na VPS opisuje tę ścieżkę, a jej agent wymaga tego samego dedykowanego użytkownika, tych samych ograniczonych tokenów i tej samej tymczasowej maszyny.

Najpierw utwardź maszynę

Niezależnie od wybranego stopnia izolacji, sama maszyna musi posiadać podstawowe zabezpieczenia przed uruchomieniem agenta: tylko klucze SSH, brak logowania jako root, domyślny firewall typu default-deny oraz automatyczne aktualizacje bezpieczeństwa. Należy wygenerować listę kontrolną tutaj i wdrożyć ją jednorazowo:

ToolHarden the box before the agent moves in

FAQ

Czy używanie --dangerously-skip-permissions na serwerze jest bezpieczne?

Nie samo w sobie. Flaga usuwa wszystkie komunikaty o zgodzie, więc pierwsza błędna komenda zostanie wykonana natychmiast po wygenerowaniu jej przez model. Staje się to akceptowalnym kompromisem tylko wtedy, gdy promień rażenia jest ograniczony: co najmniej dedykowany nieuprzywilejowany użytkownik, a w przypadku pracy bez nadzoru – kontener lub tymczasowy VPS zawierający tylko jeden projekt i jeden ograniczony token. Nigdy nie należy używać tej flagi na maszynie zawierającej poświadczenia produkcyjne lub dane, których nie można stracić.

Czy Claude Code posiada piaskownicę?

Tak. Claude Code dostarcza wbudowaną piaskownicę dla komend powłoki, uruchamianą komendą /sandbox. Używa ona bubblewrap na Linuxie oraz Seatbelt na macOS, ogranicza zapisy do katalogu projektu i przekierowuje dostęp sieciowy przez proxy, które zezwala tylko na zatwierdzone domeny. Tryb auto-allow uruchamia komendy w piaskownicy bez komunikatów, co redukuje przerwy w pracy w taki sam sposób jak flaga skip, zachowując jednocześnie barierę wymuszoną przez system operacyjny. Nie jest to pełna izolacja, dlatego należy łączyć ją z dedykowanym użytkownikiem lub dedykowaną maszyną przy pracy bez nadzoru.

Dlaczego flaga skip odmawia uruchomienia jako root?

Ponieważ root bez komunikatów o zgodzie może zmodyfikować dowolny plik i każdą usługę w systemie, Claude Code blokuje --dangerously-skip-permissions, gdy działa jako root lub pod sudo na systemach Linux i macOS. Rozwiązaniem nie jest walka z tym zabezpieczeniem. Należy utworzyć nieuprzywilejowanego użytkownika dla agenta i uruchomić go na tym koncie; granica konta jest pierwszą i najtańszą warstwą izolacji.

Czy Claude Code może odczytać moje klucze SSH i pliki .env?

Może odczytać wszystko, co może odczytać użytkownik, na którego konto został uruchomiony; nawet domyślna polityka piaskownicy pozwala na odczyt ścieżek z poświadcieniami, dopóki nie zostanie im zabronione dostęp. Należy zatem uruchamiać agenta jako osobnego użytkownika, ustawić własny katalog domowy z uprawnieniami 750 lub bardziej restrykcyjnymi, zabronić dostępu do ścieżek z poświadczeniami w ustawieniach piaskownicy i całkowicie usunąć poświadczenia produkcyjne z maszyny. Sekretu, którego nigdy nie było na maszynie, nie można odczytać ani wyciec.

Jaki jest najbezpieczniejszy sposób uruchamiania Claude Code bez nadzoru?

Tani, dedykowany VPS używany wyłącznie do pracy agenta: utwardzony w dziesięć minut, z wykonaną migawką czystego stanu, uruchamiający Claude Code pod nieuprzywilejowanym użytkownikiem z włączoną piaskownicą, z plikiem mode 600 przechowującym klucz API, z kluczem wdrożeniowym na jedno repozytorium i całą pracą na gałęziach, które zostaną zweryfikowane przed scaleniem. Jeśli proces przebiegnie nieprawidłowo, należy unieważnić jeden token i przywrócić migawkę, a żadne inne zasoby nie zostaną naruszone.