Claude Code i Codex na VPS-ach: administracja serwerami przez CLI

Zarządzam około dziesięcioma VPS-ami i prawie wszystko robię z terminala: konfigurację, diagnozę awarii i analizę logów. Od kiedy robię to z agentem (Claude Code albo Codex), jest szybciej niż z jakimkolwiek panelem. MongoDB stawiałem kiedyś kilka godzin, bo trzeba było przeczytać dokumentację, dopasować wersję do systemu, poprawić konfigurację i sprawdzić, dlaczego usługa nie wstaje. Dziś zajmuje to kilkanaście minut. To moja obserwacja z własnej praktyki, a nie benchmark.

Ta sama szybkość ma drugą stronę: pomyłka też dzieje się szybciej. Ten wpis pokazuje, do czego agent w terminalu naprawdę się przydaje i jak go ustawić, żeby nie stracić nad serwerami kontroli.

Gdzie agent oszczędza najwięcej czasu

Największy zysk nie jest w samym pisaniu komend. Jest w czytaniu. Przy awarii człowiek zwykle robi to samo: sprawdza, która usługa nie działa, zagląda do logów, szuka pierwszego błędu, a potem szuka w wyszukiwarce, co on oznacza. Agent wykonuje tę pętlę bez przełączania się między oknami.

Typowe zadania, które zlecam:

Logi systemowe. „Zobacz, dlaczego nginx zrestartował się dziś w nocy”. Agent uruchamia journalctl -u nginx --since "yesterday", filtruje błędy i streszcza, co się stało przed restartem.
Logi z Dockera. docker ps, a potem docker logs --since 1h --tail 200 <kontener>. Agent porównuje kilka kontenerów naraz, np. aplikację i bazę, i zestawia zdarzenia w czasie.
Logi baz danych. W MongoDB sprawdza plik logu i wolne zapytania, w PostgreSQL błędy połączeń i blokady. Tu przydaje się cierpliwość agenta, bo logi bazodanowe są długie i powtarzalne.
Stan zasobów. Miejsce na dysku, pamięć, otwarte porty (ss -tlnp), procesy zjadające CPU.
Konfiguracja nowej usługi. Instalacja, plik konfiguracyjny, użytkownik, reguły zapory, test, że działa.

Zasada, którą stosuję: najpierw odczyt, dopiero potem zmiana. Diagnoza polega na komendach, które niczego nie zmieniają, więc można je puszczać szeroko. Pytanie o zgodę ma sens dopiero przy zapisie.

Szybka instalacja nie zastępuje listy kontrolnej

Przy MongoDB widać najlepiej, gdzie szybkość kusi do skrótów. Agent postawi bazę w kilkanaście minut, ale wystawiona w sieci baza bez autoryzacji to jeden z klasycznych błędów. Dokumentacja MongoDB w liście kontrolnej bezpieczeństwa wymienia między innymi:

włączenie kontroli dostępu i mechanizmu uwierzytelniania,
utworzenie najpierw administratora użytkowników, a potem pozostałych kont z minimalnymi uprawnieniami,
ograniczenie interfejsów, na których baza nasłuchuje (net.bindIp), oraz zaporę przepuszczającą tylko zaufanych klientów,
TLS dla połączeń, a także szyfrowanie danych w spoczynku.

Warto zauważyć, że ta lista nie zawiera backupów. Backupy i sprawdzanie, że da się z nich odtworzyć dane, zostają po Twojej stronie.

Praktyczny sposób: po instalacji poproś agenta, żeby sam przeszedł tę listę i wskazał, co spełniono, a czego nie. Dla każdego punktu ma pokazać komendę lub fragment konfiguracji, który to potwierdza. Nie bierz na wiarę zdania „skonfigurowane”.

Uprawnienia: co agent może zrobić bez pytania

Obie aplikacje mają własny model uprawnień, i warto go znać, zanim agent dostanie dostęp do serwera.

Claude Code wymaga zatwierdzenia dla komend powłoki, poza wbudowanym zestawem poleceń tylko do odczytu, i pozwala definiować reguły allow, ask i deny, według dokumentacji uprawnień. Dobry punkt wyjścia do pracy na serwerach: na liście allow komendy diagnostyczne, a zmiany usług, instalacje i usuwanie plików zostają przy zatwierdzaniu.

Codex rozdziela dwa pojęcia: tryb piaskownicy (read-only, workspace-write, danger-full-access) i politykę zatwierdzeń (untrusted, on-request, never), zgodnie z dokumentacją piaskownicy. Do diagnozy read-only jest naturalnym wyborem. danger-full-access razem z never oznacza pracę bez żadnych granic i wolałbym go nie używać poza odizolowanym środowiskiem.

Piaskownica nie chroni serwera

Tu łatwo o błędne założenie. Piaskownica Claude Code obejmuje polecenia powłoki uruchamiane na Twoim komputerze, a zwykłe ssh, scp i rsync nie połączą się z jej wnętrza. Żeby pracować na VPS-ie, trzeba więc wyłączyć ssh z piaskownicy. Z tego wynika wniosek, który jest moją interpretacją dokumentacji: gdy agent dostaje dostęp przez SSH, to, co zrobi na serwerze, nie jest ograniczone przez jego lokalną piaskownicę. Ochrona musi leżeć po stronie serwera.

W praktyce oznacza to:

Osobny użytkownik dla agenta, bez dostępu do root. Do diagnozy wystarczy dostęp do logów (na Debianie i Ubuntu m.in. grupy adm i systemd-journal) oraz do docker tylko tam, gdzie to konieczne.
Wąskie sudo. Dopisz wyłącznie komendy, które mają sens, np. restart konkretnej usługi, zamiast pełnego sudo.
Klucz SSH tylko do tego celu, który możesz odebrać bez zmiany reszty.
Drugi kanał dostępu, czyli konsola z panelu dostawcy. O tym niżej.

Jak wygląda błąd

W lipcu 2025 głośno było o agencie Replit, który podczas zamrożenia zmian usunął produkcyjną bazę danych, jak relacjonowały heise i eWeek. Liczby w różnych relacjach się różnią, a opis opiera się głównie na wpisach poszkodowanego, więc nie podaję ich tutaj. Wniosek jest prostszy od szczegółów: polecenie „nie zmieniaj niczego” w czacie nie jest zabezpieczeniem. Zabezpieczeniem jest brak uprawnień do zapisu.

Jest też mniej spektakularny, a częstszy scenariusz. Autor jednego z blogów o zarządzaniu VPS-em przez agenta opisuje, że prośba o ograniczenie ruchu do wybranych portów skończyła się zablokowaniem także SSH i utratą dostępu w trakcie sesji. To pojedyncza relacja, nie statystyka, ale każdy, kto dotykał zapory zdalnie, zna tę pułapkę. Dlatego:

Konsola dostawcy VPS (VNC lub serial) powinna działać, zanim agent dotknie zapory, SSH lub sieci. Sprawdź to wcześniej.
Przed zmianą sshd_config lub ufw poproś o plan i o tymczasowy mechanizm cofania, np. otwartą drugą sesję SSH.
Przed zmianą danych robisz backup i sprawdzasz, że da się go odtworzyć.

Kiedy sam agent już nie wystarczy

Agent w terminalu świetnie sprawdza się przy diagnozie i jednorazowej konfiguracji. Przy dziesięciu serwerach pojawia się jednak problem powtarzalności: skąd wiem, że każdy ma tę samą konfigurację?

Wtedy dochodzą narzędzia deklaratywne. Powszechny podział, który opisują m.in. poradniki env0: Terraform lub OpenTofu tworzą serwery i zasoby, a Ansible konfiguruje to, co jest w środku. Ansible nie wymaga agenta na serwerze, bo łączy się przez SSH. Jeśli wybierasz między Terraformem a OpenTofu: HashiCorp zmienił licencję na BSL 1.1 w sierpniu 2023, a OpenTofu jest otwartoźródłową alternatywą.

Dobrze sprawdza się układ, w którym agent pisze playbook Ansible, a Ty go przeglądasz i uruchamiasz. Dostajesz szybkość agenta, ale konfiguracja zostaje w repozytorium, jest powtarzalna i da się ją przejrzeć.

Proponowany początek

Utwórz na jednym serwerze użytkownika tylko do odczytu i zleć agentowi diagnozę logów.
Zapisz, jakie komendy uruchamia, i dodaj je do listy dozwolonych.
Zmiany na produkcji zostaw przy zatwierdzaniu ręcznym, a dostęp do konsoli dostawcy przetestuj wcześniej.
Dopiero potem dołóż zapis.

Więcej o granicach dostępu agentów w innych narzędziach znajdziesz we wpisie Jak ograniczyć dostęp agenta GitHub Copilot, a o samym Claude Code w tekście Claude Code jako asystent.

Źródła: piaskownica Claude Code, uprawnienia Claude Code, piaskownica Codex, lista kontrolna bezpieczeństwa MongoDB, zmiana licencji HashiCorp, 10.08.2023. Stan: 11 października 2026.