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

Domyślnie Claude Code prosi o potwierdzenie przed wykonaniem akcji. Odczyt plików wewnątrz projektu odbywa się w tle, jednak edycja pliku lub uruchomienie polecenia powłoki wymaga wcześniejszego zatwierdzenia przez użytkownika. Można zatwierdzić pojedynczą akcję lub zezwolić na dany typ operacji do końca sesji. Te uprawnienia obowiązują tylko w ramach bieżącej sesji: po zamknięciu CLI kolejna sesja ponownie wymaga potwierdzeń. W przypadku reguł, które mają być trwałe, plik konfiguracyjny przechowuje listy zezwoleń (allow), zapytań (ask) oraz odmów (deny). Na przykład: zezwól na git status, pytaj o git push, zabroń odczytu .env. Reguły odmowy mają zawsze najwyższy priorytet. Ten bazowy poziom zabezpieczeń ulegnie zmianie, ponieważ od 14 sierpnia 2026 tryb automatyczny stanie się domyślnym, dlatego warto wiedzieć co faktycznie umożliwia każdy tryb uprawnień przed podjęciem decyzji, w jakim trybie powinien działać serwer, którego nie można stale 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 nadzoruje. Uruchamiasz długie zadanie wewnątrz tmux i idziesz spać, a agent, który zatrzymuje się, by zadać pytanie o 2 w nocy, nie wykonuje żadnej pracy do rana. Przestój kosztuje zarówno czas, jak i pieniądze, ponieważ bezczynna sesja Claude Code traci rozgrzaną pamięć podręczną promptu, a kolejna tura wymaga opłacenia jej ponownego zbudowania. 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 rezygnowania 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 kolejnych 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 sięgali po flagę pomijania (skip flag). W systemie Linux wykorzystuje ono 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 sprawdza każdą domenę pod kątem listy dozwolonych adresów. Gdy polecenie po raz pierwszy próbuje połączyć się z nową domeną, Claude Code prosi o zatwierdzenie.

Włącz tę funkcję 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 uniemożliwia bubblewrap tworzenie wymaganych przestrzeni nazw użytkownika (user namespaces). 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 zatwierdzania: polecenia wewnątrz środowiska uruchamiają się bez żadnych zapytań, ponieważ wymuszona granica wykonuje pracę, którą wcześniej wykonywało zapytanie. Polecenia, których nie można uruchomić wewnątrz środowiska izolowanego, wracają do standardowego przepływu uprawnień, więc w przypadku działań nietypowych system nadal poprosi o potwierdzenie. Dla większości procesów serwerowych jest to właściwy zamiennik flagi pomijania, ponieważ dzięki wymuszonej przez system operacyjny granicy otrzymuje się znacznie mniej pytań, 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 zablokujesz te ścieżki; ustawienie sandbox.credentials służy właśnie do tego celu. Proxy sieciowe sprawdza nazwy domen i nie analizuje samej treści ruchu, więc szerokie zezwolenie, takie jak github.com, nadal pozostawia możliwość przesyłania 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 nadal 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.

Przekaż klucz API wyłącznie agentowi. Umieść go w pliku należącym do użytkownika agenta z uprawnieniami 600 i wczytuj 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 zabezpiecz dostęp w drugą stronę. W systemach Debian i Ubuntu katalogi domowe są często tworzone z uprawnieniami do odczytu dla wszystkich użytkowników, dlatego należy ograniczyć dostęp za pomocą chmod 750 /home/youruser. Sprawdź uprawnienia poleceniem ls -ld /home/* i popraw wszystko, co jest widoczne dla konta agenta.

Ogranicz zakres każdego tokena. Token GitHub o ograniczonym zakresie, przypisany do jednego repozytorium, lub klucz wdrożeniowy (deploy key) dla konkretnego projektu sprawiają, że wyciek danych uwierzytelniających dotyczy tylko jednego projektu, a nie całego konta. Jeśli korzystasz z piaskownicy (sandbox), skonfiguruj jej ustawienia tak, aby ~/.ssh oraz ~/.aws były zabronione nawet dla operacji odczytu. Nie przechowuj produkcyjnych danych uwierzytelniających na serwerze, ponieważ agent nie może ujawnić sekretu, którego tam nie ma. Jeśli sekrety znajdują się w samodzielnie hostowanym menedżerze haseł, przechowuj go na innym serwerze niż agent i poddaj go oddzielnej weryfikacji, ponieważ słabymi punktami Vaultwarden są token administratora oraz plik kopii zapasowej, a nie sam zaszyfrowany skarbiec.

Git jako sieć bezpieczeństwa

Każda zmiana wprowadzona przez agenta powinna podlegać weryfikacji i możliwości wycofania. Git zapewnia obie te funkcje, jeśli agent pracuje na osobnej gałęzi:

git switch -c agent/refactor-auth

Po zakończeniu działania przejrzyj zmiany za pomocą git diff main...agent/refactor-auth, scal poprawne fragmenty i usuń gałąź, jeśli operacja nie przyniosła oczekiwanych rezultatów. Zmiany obejmujące trzy pliki są znacznie łatwiejsze do przeanalizowania niż te, które nadpisują połowę modułu. Jest to praktyczne uzasadnienie dla umiejętności ograniczania działań agenta do najmniejszej skutecznej zmiany. Zabezpiecz główną gałąź w serwisie hostingowym, aby token agenta nie mógł do niej wypychać zmian ani wymuszać ich nadpisywania. Historia commitów pełni rolę dziennika audytu działań wykonanych podczas nieobecności administratora, 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.