Bezpieczne uruchamianie Claude Code na serwerze

Co oznacza bezpieczne uruchamianie Claude Code na serwerze

Aby bezpiecznie uruchamiać Claude Code na serwerze, należy zachować włączone monity o uprawnienia, uruchamiać narzędzie jako dedykowany użytkownik bez uprawnień roota oraz zapewnić procesom działającym bez nadzoru rzeczywistą izolację zamiast zaufania. Można w tym celu wykorzystać wbudowany 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ą. Taki kompromis może być uzasadniony w przypadku zadań wykonywanych bez nadzoru, ale tylko wewnątrz środowiska ograniczającego zasięg potencjalnie szkodliwych poleceń. Niniejszy przewodnik wyjaśnia, co faktycznie zmienia ta flaga oraz jak zbudować taką barierę, stosując kolejne poziomy izolacji.

Co Claude Code może zrobić na Twoim serwerze

Claude Code to agent programistyczny działający w terminalu. Odczytuje i zapisuje pliki oraz wykonuje polecenia powłoki jako użytkownik, który go uruchomił. Na tym polega główna wartość tego narzędzia: potrafi sklonować repozytorium, edytować kod, uruchomić testy, odczytać błędy i naprawić kod w pętli, bez konieczności ręcznego wpisywania każdego polecenia. Jeśli narzędzie nie zostało jeszcze skonfigurowane na serwerze, uruchamianie Claude Code na VPS z użyciem tmux zawiera informacje o instalacji i obsłudze sesji. Ta strona opisuje uprawnienia, jakie otrzymuje agent po uruchomieniu.

Ryzyko wynika z faktu, że proces wykonujący polecenia powłoki w imieniu użytkownika może zrobić wszystko to, co sam użytkownik. Może odczytać ~/.ssh/id_ed25519, ~/.aws/credentials oraz każdy plik .env, do którego użytkownik ma dostęp. Może uruchomić curl i wysłać dane do dowolnego hosta, z którym serwer może się połączyć. Może uruchomić git push --force. Agent nie posiada własnych motywacji. Niebezpieczeństwo polega na tym, że zadanie może zostać wykonane błędnie lub że tekst odczytany podczas pracy zawierał instrukcje napisane przez kogoś innego: pobraną stronę internetową lub komentarz w zgłoszeniu, które agent miał naprawić. Ten drugi przypadek nazywany jest wstrzykiwaniem promptu (prompt injection) i dlatego założenie, że „model jest zazwyczaj rozsądny”, nie stanowi strategii bezpieczeństwa. Instrukcje mogą również pochodzić z wewnątrz systemu, ponieważ dwie sesje Claude Code na tym samym serwerze mogą przesyłać sobie tekst, a wiadomość z sesji równoległej jest dla odbierającego agenta po prostu kolejnym tekstem do odczytania. Należy planować zabezpieczenia na wypadek nieprawidłowego działania, a nie typowego przebiegu pracy.

System uprawnień w prostych słowach

W trybie Manual, Claude Code prosi o potwierdzenie przed wykonaniem akcji. Odczyt plików wewnątrz projektu odbywa się w tle, ale edycja pliku lub uruchomienie polecenia powłoki wymaga uprzedniego zatwierdzenia konkretnej zmiany lub komendy. Można zatwierdzić pojedynczą akcję lub wybrać opcję braku ponownego pytania. W przypadku edycji plików wybór ten obowiązuje do końca sesji, natomiast dla poleceń powłoki jest zapisywany na stałe dla danego repozytorium i komendy, więc szybkie zatwierdzenie na serwerze pozostaje aktywne po zakończeniu sesji. W przypadku reguł, które mają być zachowane, plik ustawień przechowuje trwałe listy zezwoleń (allow), zapytań (ask) oraz blokad (deny). Na przykład: zezwól na git status, pytaj przy git push, blokuj odczyt .env. Reguły blokujące mają zawsze pierwszeństwo. Ten standardowy poziom zabezpieczeń uległ zmianie. Tryb Auto, w którym klasyfikator weryfikuje akcje zamiast użytkownika, stał się domyślny dla nowych sesji w planach Pro, Max i Team od 14 sierpnia 2026 roku. Od wersji Claude Code v2.1.283 jest to wbudowany tryb startowy dla interaktywnych sesji terminalowych oraz VS Code w każdym planie, chyba że ustawiono domyślny tryb na sztywno. Warto zatem wiedzieć, co faktycznie umożliwia każdy tryb uprawnień, zanim zdecydujesz, w jakim trybie powinien działać serwer, którego nie możesz monitorować.

Projekt ten zakłada, że człowiek obserwuje terminal, co jest prawdą w przypadku laptopa. Na serwerze często chodzi o to, że nikt go nie obserwuje. Uruchamiasz długie zadanie wewnątrz tmux i kończysz pracę, a agent, który zatrzymuje się, by zadać pytanie o 2 w nocy, nie wykonuje żadnej pracy do rana. Przestój kosztuje zarówno pieniądze, jak i czas, ponieważ bezczynna sesja Claude Code traci rozgrzaną pamięć podręczną promptu, a kolejna tura wymaga opłaty za jej ponowne zbudowanie. To rzeczywisty powód, dla którego użytkownicy sięgają po flagę pomijania (skip) na serwerach, 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 krok zatwierdzania. Edycje plików odbywają się bez pytania o zgodę. Polecenia powłoki są wykonywane bez potwierdzenia. Pomijane są również sprawdzania ścieżek chronionych, które standardowo zabezpieczają wrażliwe lokalizacje. Jawne reguły odmowy (deny rules) nadal obowiązują, a nieliczne, skrajnie ryzykowne operacje nadal wymagają potwierdzenia, jednak ogólna zasada działania jest prosta: wszystko, co model zdecyduje się uruchomić, zostanie wykonane.

W kontekście serwerowym istotne są dwa fakty dotyczące tej flagi. Po pierwsze, jest ona blokowana, gdy Claude Code działa jako root lub z użyciem sudo w systemach Linux i macOS, ponieważ użytkownik root bez monitów może zmienić dowolny plik lub usługę w systemie. Agent i tak powinien korzystać z własnego, nieuprzywilejowanego konta, a flaga ta wymusza takie podejście. Po drugie, flaga w żaden sposób nie zmienia zachowania modelu. Usuwa ona człowieka z pętli decyzyjnej, nie zmieniając niczego innego, więc każdy błąd, który zostałby wykryty podczas zatwierdzania, teraz zostanie wykonany.

Oto uczciwa kalkulacja. W przypadku pominięcia uprawnień pytanie dotyczące bezpieczeństwa zmienia się z „czy agent zrobi coś złego” na „jak duże szkody może wyrządzić jedno błędne działanie”. Należy przestać próbować kontrolować każdą decyzję i zacząć kontrolować zasięg potencjalnych szkód (blast radius). Rozwiązaniem jest izolacja, którą wdraża się stopniowo.

Wbudowane środowisko izolowane Claude Code

Przed przejściem do dalszych kroków należy wiedzieć, że Claude Code udostępnia teraz środowisko izolowane (sandbox) na poziomie systemu operacyjnego dla uruchamianych poleceń. Eliminuje to większość powodów, dla których użytkownicy korzystali z flagi pomijania (skip flag). W systemie Linux narzędzie wykorzystuje bubblewrap do izolacji systemu plików oraz socat do kierowania ruchu sieciowego przez proxy. Wewnątrz środowiska izolowanego polecenie może zapisywać dane tylko w katalogu projektu oraz w tymczasowym katalogu sesji. Dostęp do sieci jest możliwy wyłącznie przez proxy, które weryfikuje każdą domenę względem listy dozwolonych adresów. Gdy polecenie po raz pierwszy próbuje połączyć się z nową domeną, Claude Code prosi o zatwierdzenie; w trybie automatycznym nowy host jest weryfikowany przez klasyfikator.

Środowisko można włączyć poleceniem /sandbox wewnątrz sesji. W systemach Ubuntu i Debian należy najpierw zainstalować dwa wymagane pakiety:

sudo apt install bubblewrap socat

W systemie Ubuntu 24.04 i nowszych domyślna polityka AppArmor blokuje tworzenie przestrzeni nazw użytkownika (user namespaces) wymaganych przez bubblewrap. Panel środowiska izolowanego informuje o brakujących elementach, a dokumentacja środowiska izolowanego Claude Code zawiera krótki profil AppArmor, który rozwiązuje ten problem.

Środowisko izolowane posiada tryb automatycznego zezwalania (auto-allow): polecenia wewnątrz środowiska uruchamiają się bez żadnych pytań, ponieważ wymuszona granica wykonuje pracę, którą wcześniej wykonywały monity. Polecenia, których nie można uruchomić wewnątrz środowiska izolowanego, wracają do standardowego przepływu uprawnień, więc nietypowe działania nadal wymagają potwierdzenia. W przypadku większości zadań serwerowych jest to właściwy zamiennik flagi pomijania, ponieważ liczba pytań jest znacznie mniejsza dzięki wymuszonej systemowo granicy, zamiast całkowitego ich braku.

Należy mieć świadomość ograniczeń tego rozwiązania. Domyślnie polecenie w środowisku izolowanym nadal może odczytywać większość systemu plików, w tym pliki z danymi uwierzytelniającymi, chyba że ścieżki te zostaną zablokowane; ustawienie sandbox.credentials służy właśnie do tego celu. Proxy sieciowe sprawdza nazwy domen, ale nie analizuje samego ruchu, więc szerokie zezwolenie, takie jak github.com, nadal umożliwia przesyłanie danych na zewnątrz. Docker nie działa wewnątrz tego środowiska. Środowisko izolowane znacząco podnosi poziom bezpieczeństwa, jednak nie stanowi pełnej bariery izolacyjnej, dlatego poniższe kroki pozostają istotne.

Drabina izolacji

Trzy szczeble o rosnącym stopniu izolacji. Należy wybrać najniższy szczebel, który jest odpowiedni dla pozostałych usług działających na serwerze.

Szczebel 1: dedykowany użytkownik bez uprawnień (unprivileged user). Agent otrzymuje własne konto, własny katalog domowy, własny katalog projektu oraz brak dostępu do sudo:

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

Granica konta chroni pliki użytkownika: klucze SSH oraz wszystkie inne projekty na maszynie. Umożliwia to również użycie flagi skip, ponieważ flaga ta odmawia uruchomienia z uprawnieniami root. Jest to ta sama zasada, co uruchamianie każdej usługi jako użytkownik bez uprawnień, zastosowana w odniesieniu do agenta. Czego szczebel 1 nie ogranicza: sieci oraz wszystkiego na serwerze, co jest dostępne do odczytu dla wszystkich (world-readable).

Szczebel 2: kontener. Anthropic publikuje referencyjny devcontainer, który uruchamia Claude Code jako użytkownik niebędący rootem, z regułami firewalla ograniczającymi hosty, z którymi agent może się łączyć; własnoręcznie zbudowany kontener spełnia to samo zadanie. System plików zostaje ograniczony do zamontowanych wolumenów, a ruch wychodzący do reguł zdefiniowanych dla kontenera. Jest to właściwy środkowy szczebel, gdy serwer hostuje inne istotne usługi. Ograniczeniem jest fakt, że kontenery współdzielą jądro hosta, a jedno nieostrożne zamontowanie wolumenu niweluje tę barierę; przekazanie kontenerowi /var/run/docker.sock pozwala mu na dostęp do całego hosta.

Szczebel 3: dedykowany VPS. Najsilniejszy szczebel jest zarazem najbardziej bezpośredni: należy przydzielić agentowi całą maszynę, na której nie znajdują się żadne istotne dane. Mały VPS kosztuje kilka dolarów miesięcznie. Należy go skonfigurować zgodnie z procedurą pierwszych dziesięciu minut na nowym VPS, wykonać snapshot czystego stanu i pozwolić agentowi na pracę. Nic innego tam nie działa. Brak osobistych kluczy SSH, jedynie klucz deploy key ograniczony do jednego repozytorium. Brak poświadczeń chmurowych, brak danych produkcyjnych. Gdy praca przebiegnie nieprawidłowo lub gdy wymagany jest czysty stan, należy przywrócić snapshot albo zniszczyć i odbudować maszynę w kilka minut. Promień rażenia ogranicza się do kosztu wynajmu. Jest to konfiguracja, w której --dangerously-skip-permissions przestaje być przerażające, ponieważ najgorszym realistycznym skutkiem jest konieczność odbudowy serwera i unieważnienia jednego tokena.

Szczeble można łączyć. Sapiaskowany agent, uruchomiony jako użytkownik bez uprawnień na jednorazowym VPS, nie generuje niemal żadnych dodatkowych kosztów i sprawia, że historie o awariach stają się nieistotne. Nuda jest celem.

Ochrona danych uwierzytelniających

Zasada nadrzędna: użytkownik agenta nie może mieć uprawnień do odczytu sekretów należących do innych usług.

Klucz API należy przekazać wyłącznie agentowi. Należy umieścić go w pliku, którego właścicielem jest użytkownik agenta, z uprawnieniami 600, a następnie wczytywać go przy uruchamianiu 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 ograniczyć dostęp w drugą stronę. W starszych instalacjach Debian i Ubuntu oraz dla kont utworzonych podczas instalacji, katalogi domowe mogą być czytelne dla wszystkich użytkowników systemu, dlatego należy zaostrzyć uprawnienia: chmod 750 /home/youruser. Należy sprawdzić dostęp za pomocą ls -ld /home/* i naprawić wszelkie elementy, które konto agenta może wyświetlić.

Należy ograniczyć zakres każdego tokena. Token GitHub o ograniczonym zakresie, przypisany do jednego repozytorium, lub klucz wdrożeniowy (deploy key) dla konkretnego repozytorium sprawiają, że wyciek danych uwierzytelniających dotyczy tylko jednego projektu, a nie całego konta. W przypadku korzystania z piaskownicy (sandbox), należy skonfigurować jej uprawnienia tak, aby ~/.ssh oraz ~/.aws były zabronione nawet w trybie odczytu. Dane uwierzytelniające środowiska produkcyjnego nie powinny znajdować się na serwerze, ponieważ agent nie może ujawnić sekretu, którego w systemie nie ma. Jeśli sekrety te są przechowywane w samodzielnie hostowanym menedżerze haseł, należy umieścić go na innym serwerze niż agent i poddać go odrębnej weryfikacji, ponieważ słabymi punktami Vaultwarden są token administratora oraz plik kopii zapasowej, a nie sam zaszyfrowany skarbiec.

Git jako mechanizm bezpieczeństwa

Każda zmiana zatwierdzona przez agenta podlega przeglądowi i wycofaniu. Git zapewnia obie te funkcje automatycznie, jeśli agent pracuje na gałęzi i wykonuje commity w trakcie pracy:

git switch -c agent/refactor-auth

Praca, której agent nie zatwierdził, nie posiada takiej ochrony: polecenie git reset --hard odrzuca niezatwierdzone zmiany w śledzonych plikach, a Git w ogóle nie obejmuje niczego poza repozytorium. Po zakończeniu działania sprawdź wykonane operacje za pomocą git diff main...agent/refactor-auth, a następnie użyj git status oraz git diff HEAD na gałęzi, aby sprawdzić zmiany, które nie zostały zatwierdzone. Scal poprawne zmiany, a jeśli działanie nie przyniosło efektu, usuń gałąź. Przeglądanie zmian w trzech plikach jest znacznie łatwiejsze niż analizowanie przebudowy połowy modułu, co stanowi praktyczne uzasadnienie dla umiejętności wymuszania na agencie wprowadzania najmniejszych działających zmian. Zabezpiecz główną gałąź po stronie platformy hostingowej, aby token agenta nie mógł do niej wypychać zmian ani wykonywać force-push w żadnym miejscu. Historia commitów pełni rolę dziennika audytu działań wykonanych podczas Twojej nieobecności, co jest bardziej wartościowe niż jakakolwiek ilość przewiniętego tekstu w terminalu.

Sieć jest częścią obszaru rażenia

Agent może uruchomić curl. To zdanie stanowi istotę problemu ruchu wychodzącego: wszystko, co agent może odczytać, może również wysłać w dowolne miejsce, co może wykorzystać agent podatny na prompt injection. Zwykły użytkownik bez uprawnień nie ogranicza tego w żaden sposób, ponieważ każdy użytkownik ma dostęp do wszystkiego, co jest osiągalne z poziomu serwera. Piaskownica (sandbox) ogranicza to poprzez domenę za pomocą własnego proxy. Kontener może ograniczyć to za pomocą własnych reguł firewalla. Dedykowany VPS ogranicza zakres danych, które mogą wyciec, co jest najbardziej solidnym z tych trzech rozwiązań.

Nie należy próbować rozwiązywać problemu ruchu wychodzącego wyłącznie za pomocą ufw. ufw domyślnie zezwala na cały ruch wychodzący, a tworzenie reguł wychodzących, które jednocześnie umożliwiają działanie apt, npm, git oraz API Claude, jest żmudnym zadaniem, które często kończy się cichymi awariami. Zamiast tego należy wybrać ograniczenie na poziomie piaskownicy, kontenera lub maszyny, gdzie lista dozwolonych domen lub odizolowana maszyna wykonują to zadanie w sposób przejrzysty.

Jeśli budowany jest własny agent korzystający z API, zamiast uruchamiania Claude Code, obowiązuje ten sam tok rozumowania. Budowa agenta AI z wykorzystaniem Claude na VPS omawia tę ścieżkę, a taki agent wymaga tego samego dedykowanego użytkownika, ograniczonych zakresowo tokenów oraz jednorazowego środowiska uruchomieniowego.

Zabezpieczanie systemu

Niezależnie od wybranego poziomu, maszyna wymaga podstawowej konfiguracji przed instalacją agenta: logowanie wyłącznie przy użyciu kluczy SSH, wyłączenie logowania na konto root, domyślna polityka firewall typu deny oraz automatyczne aktualizacje bezpieczeństwa. Przygotuj listę kontrolną i wykonaj po kolei wszystkie kroki:

FAQ

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

Samo w sobie nie. Flaga ta usuwa wszystkie monity o potwierdzenie, więc każde błędne polecenie zostanie wykonane w momencie wygenerowania go przez model. Staje się to akceptowalnym kompromisem, gdy zasięg potencjalnych szkód jest ograniczony: wymagane jest co najmniej konto użytkownika bez uprawnień, a w przypadku pracy w pełni zautomatyzowanej – kontener lub tymczasowy VPS, który obsługuje jeden projekt i posiada ograniczony zakres tokenów. Nigdy nie należy używać tej flagi na maszynie przechowującej dane produkcyjne lub poświadczenia, których utrata jest niedopuszczalna.

Czy Claude Code posiada piaskownicę (sandbox)?

Tak. Claude Code zawiera wbudowaną piaskownicę dla poleceń powłoki, uruchamianą za pomocą polecenia /sandbox. Wykorzystuje ona bubblewrap w systemie Linux oraz Seatbelt w systemie macOS, ogranicza zapis do katalogu projektu i kieruje ruch sieciowy przez proxy, które zezwala jedynie na dostęp do zatwierdzonych domen. Tryb automatycznego zatwierdzania uruchamia polecenia w piaskownicy bez wyświetlania monitów, co eliminuje przestoje w sposób podobny do flagi pomijania, przy jednoczesnym zachowaniu bariery wymuszanej przez system operacyjny. Nie jest to pełna izolacja, dlatego w przypadku pracy bez nadzoru należy korzystać z dedykowanego użytkownika lub odseparowanej maszyny.

Dlaczego flaga pomijania odmawia działania z uprawnieniami root?

Ponieważ użytkownik root bez monitów o potwierdzenie może zmodyfikować dowolny plik i usługę w systemie, Claude Code blokuje --dangerously-skip-permissions, gdy jest uruchamiany jako root lub przez sudo w systemach Linux i macOS. Rozwiązaniem nie jest omijanie tego zabezpieczenia. Należy utworzyć użytkownika bez uprawnień dla agenta i uruchamiać go na tym koncie; granica tego konta stanowi pierwszą i najtańszą warstwę zabezpieczeń.

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

Agent może odczytać wszystko, do czego ma dostęp użytkownik, na którym jest uruchomiony, a domyślna polityka piaskownicy pozwala na odczyt ścieżek z poświadczeniami, dopóki nie zostaną one zablokowane. Dlatego należy uruchamiać agenta na dedykowanym koncie, utrzymywać katalog domowy z uprawnieniami 750 lub bardziej restrykcyjnymi, blokować ścieżki do poświadczeń w ustawieniach piaskownicy i całkowicie unikać przechowywania sekretów produkcyjnych na tej maszynie. Sekret, który nigdy nie trafił do środowiska agenta, nie może zostać odczytany ani wyciec.

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

Tani, dedykowany VPS używany wyłącznie do pracy agenta: zabezpieczony w dziesięć minut, z czystym snapshotem, uruchamiający Claude Code na koncie użytkownika bez uprawnień z włączoną piaskownicą, plikiem z kluczem API o uprawnieniach 600, kluczem deploy key przypisanym do konkretnego repozytorium oraz pracą wykonywaną na gałęziach, które podlegają weryfikacji przed scaleniem. Jeśli proces zakończy się niepowodzeniem, wystarczy unieważnić jeden token i przywrócić snapshot, co gwarantuje, że żadne inne zasoby nie zostaną naruszone.