Instalacja Claude Code i ChatGPT Codex na serwerze Linux: krok po kroku

Ten poradnik prowadzi od świeżo zainstalowanego serwera z Debianem lub Ubuntu do działającego agenta AI, który analizuje logi, sprawdza konfiguracje i wykonuje zadania konserwacyjne. Konfigurujemy Claude Code (Anthropic) i Codex CLI (OpenAI, narzędzie wiersza poleceń od twórców ChatGPT), oba na osobnym koncie użytkownika z ograniczonymi uprawnieniami, a jako trzecią możliwość pokazujemy Gemini CLI (Google). Wszystkie polecenia przetestowaliśmy na serwerze root KVM KernelHost z Debianem 13 i Ubuntu 24.04. Czym w ogóle jest serwer zarządzany przez AI i jakie istnieją architektury, opisuje artykuł Serwer zarządzany przez AI: bezpieczne łączenie agentów AI.

Stan na wrzesień 2026. Narzędzia szybko się rozwijają; w razie wątpliwości sprawdź opcje za pomocą claude --help, codex --help lub gemini --help.

Wymagania wstępne

• Serwer root z Debianem 12 lub 13 albo Ubuntu 22.04 lub 24.04 i dostępem root przez SSH. W systemach AlmaLinux i Rocky Linux kroki są takie same, tylko do obsługi pakietów służy dnf zamiast apt.
• Wykonane podstawowe zabezpieczenia: logowanie SSH kluczem, zapora, automatyczne aktualizacje bezpieczeństwa. Wszystko to omawia lista kontrolna dla nowych serwerów root.
• Konto w Anthropic (Claude Pro, Max lub Team) albo klucz API, konto ChatGPT (Plus, Pro lub Team) albo klucz API OpenAI. Jeśli chcesz skonfigurować tylko jedno narzędzie, wystarczy Ci jedno z nich.
• Wychodzący ruch HTTPS do api.anthropic.com i api.openai.com. Na serwerach KernelHost jest on domyślnie dozwolony, a jeśli używasz własnej restrykcyjnej zapory, musi ona przepuszczać ten ruch.

Jaki serwer wystarczy dla agenta AI?

Agent AI nie potrzebuje na serwerze specjalnego sprzętu ani GPU, bo model językowy działa u dostawcy. Na serwerze działają tylko narzędzie wiersza poleceń i Node.js, które podczas sesji zajmują zwykle łącznie kilkaset megabajtów pamięci operacyjnej. Dla serwera, na którym poza tym niewiele działa, wystarczą 2 vCPU i 4 GB RAM. Jeśli serwer obsługuje równolegle strony internetowe, bazy danych lub serwery gier, zaplanuj dla agenta około 1 GB zapasu pamięci operacyjnej. Serwer root KVM od KernelHost jest gotowy w około 30 sekund, rozliczany w modelu PrePaid bez minimalnego okresu umowy, więc nadaje się też na system testowy, na którym najpierw wypróbujesz agenta.

Krok 1: utworzyć osobnego użytkownika i ograniczyć sudo

Agent nigdy nie działa jako root. Dostaje własne konto, a przez białą listę sudo dokładnie te polecenia, których potrzebuje. Zacznij od kilku poleceń odczytowych i rozszerzaj listę, gdy zadanie naprawdę tego wymaga.

sudo adduser --disabled-password --gecos "KI-Agent" aiagent
sudo tee /etc/sudoers.d/aiagent >/dev/null <<'EOF'
aiagent ALL=(root) NOPASSWD: /usr/bin/journalctl *, /usr/bin/systemctl status *, /usr/bin/systemctl restart nginx, /usr/bin/apt-get update, /usr/bin/apt-get upgrade -y, /usr/bin/tail *, /usr/bin/df *, /usr/bin/ss *
EOF
sudo chmod 440 /etc/sudoers.d/aiagent
sudo visudo -cf /etc/sudoers.d/aiagent

Ostatni wiersz sprawdza składnię. Błąd w pliku sudoers może zablokować sudo dla wszystkich, dlatego to sprawdzenie jest zawsze obowiązkowe. --disabled-password sprawia, że nikt nie zaloguje się hasłem jako aiagent; na to konto przełączasz się później poleceniem sudo -iu aiagent. Jak w ogóle działają użytkownicy sudo, wyjaśnia artykuł Zakładanie użytkownika sudo w Linuksie.

Precyzyjne prawa zapisu zamiast edytora przez sudo

Jeśli agent ma zmieniać pliki w /etc, nie udostępniaj mu nano przez sudo (w ten sposób dałoby się edytować każdy plik, także /etc/sudoers), tylko pracuj z grupą i precyzyjnie nadanymi prawami zapisu, na przykład setfacl -m u:aiagent:rw /etc/nginx/sites-available/meine-seite.conf. Na początek w zupełności wystarczy, że agent proponuje zmiany, a Ty je wprowadzasz.

To samo dotyczy poleceń z symbolami wieloznacznymi na białej liście. /usr/bin/tail * pozwala agentowi czytać każdy plik, do którego ma dostęp root, także pliki z danymi dostępowymi. Kto tego nie chce, podaje dozwolone ścieżki wprost, na przykład /usr/bin/tail -n 200 /var/log/nginx/error.log.

Krok 2: zainstalować Node.js 22

Oba narzędzia działają na Node.js. Claude Code wymaga co najmniej wersji 18, Codex CLI co najmniej 22, dlatego instalujemy 22 LTS. Repozytoria Debiana 12 zawierają za starą wersję, aktualną udostępnia NodeSource:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version
npm --version

Alternatywa bez uprawnień root: nvm

Kto nie chce uruchamiać skryptów z internetu z uprawnieniami root, używa nvm w katalogu domowym użytkownika agenta; wtedy całość obywa się zupełnie bez uprawnień root. Polecenie instalacyjne nvm skopiuj z pliku README projektu, a potem wystarczą trzy wiersze:

nvm install 22
nvm alias default 22
node --version

Szczegóły i inne sposoby opisuje poradnik instalacji Node.js na Debianie.

Krok 3: zainstalować Claude Code i zalogować się

Od tego miejsca pracujemy na koncie agenta:

sudo -iu aiagent
curl -fsSL https://claude.ai/install.sh | bash
claude --version

Natywny instalator umieszcza Claude Code w ~/.local/bin, a program sam dba o swoje aktualizacje. Alternatywnie można go zainstalować przez npm poleceniem npm install -g @anthropic-ai/claude-code; jeśli zakończy się to błędem EACCES, pomoże sekcja o rozwiązywaniu problemów poniżej.

Logowanie na serwerze bez przeglądarki

Przy pierwszym uruchomieniu claude narzędzie prosi o zalogowanie. W przypadku konta Claude zwykle otwiera przeglądarkę; na serwerze bez przeglądarki wyświetla adres i kod, który potwierdzasz na laptopie lub smartfonie. Logowanie obowiązuje potem dla tego użytkownika na tym serwerze, dopóki się nie wylogujesz.

Klucz API do skryptów i zadań cron

Do skryptów i zadań cron lepszym wyborem jest klucz API:

echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> ~/.bashrc
chmod 600 ~/.bashrc
source ~/.bashrc
claude -p "Odpowiedz tylko słowem OK" 

Klucz znajduje się wtedy wyłącznie w katalogu domowym użytkownika agenta, a tego katalogu inni użytkownicy nie mogą czytać. W konsoli Anthropic utwórz klucz z miesięcznym limitem wydatków, wtedy sesja, która wymknie się spod kontroli, nie narazi Cię na wysokie koszty. Samego klucza nigdy nie wpisuj do zadania dla agenta ani do pliku, którego zawartość agent ma wypisać.

Krok 4: skonfigurować Claude Code dla serwera

Plik z zasadami CLAUDE.md

Claude Code przy starcie czyta plik CLAUDE.md w bieżącym katalogu. Zapisane są w nim zasady obowiązujące w każdej sesji. Utwórz w katalogu domowym agenta katalog roboczy z tym plikiem:

mkdir -p ~/server && cd ~/server
cat > CLAUDE.md <<'EOF'
# Zasady dla tego serwera
- To jest serwer produkcyjny (Debian 13, nginx, PHP-FPM, MariaDB).
- Polecenia odczytowe (journalctl, systemctl status, tail, df, ss) są dozwolone w każdej chwili.
- Przed każdym poleceniem zapisującym krótko wyjaśnij, co ono zmienia, i poczekaj na zatwierdzenie.
- Nigdy nie usuwaj pakietów, nigdy nie kasuj plików w /var/lib, nigdy nie twórz ani nie usuwaj użytkowników.
- Nigdy nie powtarzaj w wynikach haseł, kluczy ani danych klientów.
- Na końcu każdego zadania podaj podsumowanie w trzech zdaniach.
EOF

Plik z czasem się rozrasta. Za każdym razem, gdy agent zrobi coś inaczej, niż chcesz, dopisz poprawkę do pliku jako nową zasadę. Po kilku tygodniach plik dość dokładnie odzwierciedla sposób pracy na Twoim serwerze.

Biała lista w settings.json

Do tego dochodzi biała lista narzędzi, dzięki której Claude Code wykonuje polecenia odczytowe bez pytania, a przy wszystkich innych prosi o zgodę. Plik ~/.claude/settings.json obowiązuje dla danego użytkownika:

mkdir -p ~/.claude
cat > ~/.claude/settings.json <<'EOF'
{
  "permissions": {
    "allow": [
      "Bash(sudo journalctl:*)",
      "Bash(sudo systemctl status:*)",
      "Bash(sudo tail:*)",
      "Bash(df:*)",
      "Bash(free:*)",
      "Bash(ss:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo rm:*)",
      "Bash(dd:*)",
      "Bash(mkfs:*)"
    ]
  }
}
EOF

Czarna lista to dodatkowa siatka asekuracyjna, a nie mur: to samo polecenie można zapisać na wiele sposobów. Właściwą granicę wyznacza biała lista sudo z kroku 1, bo czego nie wolno użytkownikowi, tego nie wolno też agentowi.

Pierwsze zadanie w trybie interaktywnym

Teraz pierwsze zadanie, interaktywnie:

cd ~/server && claude
> Podsumuj błędy z journalctl z ostatnich 24 godzin i wymień trzy najczęstsze przyczyny.

Bez nadzoru jako zadanie cron

A to samo zadanie bez nadzoru, na przykład jako codzienne zadanie cron o 7:00, którego wynik przychodzi e-mailem:

0 7 * * * cd /home/aiagent/server && /home/aiagent/.local/bin/claude -p "Podsumuj błędy i ostrzeżenia z journalctl z ostatnich 24 godzin. Podaj usługę, godzinę i prawdopodobną przyczynę." --allowedTools "Bash(sudo journalctl:*)" 2>&1 | mail -s "Dzienny raport serwera" admin@example.com

Opcja -p uruchamia Claude Code bez sesji interaktywnej, a --allowedTools ogranicza narzędzia dokładnie do tego, czego potrzebuje dane uruchomienie. Operacje zapisu nie powinny trafiać do uruchomień bez nadzoru. Jak w ogóle konfiguruje się zadania cron, opisuje artykuł Konfiguracja zadania cron w Linuksie.

Krok 5: zainstalować Codex CLI (ChatGPT) i zalogować się

Instalacja i logowanie

Codex CLI to narzędzie OpenAI, które przenosi modele napędzające ChatGPT do wiersza poleceń. Instalacja na tym samym koncie użytkownika:

npm install -g @openai/codex
codex --version

Logowanie odbywa się kontem ChatGPT (Plus, Pro lub Team): uruchom codex, wybierz „Sign in with ChatGPT” i otwórz wyświetlony adres na urządzeniu z przeglądarką. Do skryptów ustaw zamiast tego klucz API z platformy OpenAI:

echo 'export OPENAI_API_KEY="sk-..."' >> ~/.bashrc
source ~/.bashrc

Piaskownica i tryb zatwierdzania w config.toml

Codex ma własną piaskownicę i tryb zatwierdzania. Jedno i drugie ustawia się w ~/.codex/config.toml; dla serwera produkcyjnego sensowne jest takie połączenie:

mkdir -p ~/.codex
cat > ~/.codex/config.toml <<'EOF'
approval_policy = "on-request"
sandbox_mode = "workspace-write"
EOF

workspace-write zezwala na zapis tylko w bieżącym katalogu roboczym, a on-request sprawia, że na wszystko poza tym agent prosi o zgodę. Poziom danger-full-access znosi oba ograniczenia i nie ma czego szukać na systemie produkcyjnym.

Zasady w AGENTS.md

Zasady takie jak w CLAUDE.md Codex czyta z pliku AGENTS.md w katalogu roboczym; możesz użyć tej samej treści:

cp ~/server/CLAUDE.md ~/server/AGENTS.md
cd ~/server && codex "Sprawdź, czy działają wszystkie włączone usługi systemd, i wypisz te, które zawiodły, razem z ostatnim komunikatem błędu."

Do uruchomień bez nadzoru służy codex exec "Aufgabe", odpowiednik claude -p.

Krok 6: Gemini CLI jako trzecia możliwość

Gemini CLI to narzędzie wiersza poleceń od Google, które działa na tej samej zasadzie. Również wymaga Node.js i instaluje się je na tym samym koncie użytkownika:

npm install -g @google/gemini-cli
gemini --version

Przy pierwszym uruchomieniu gemini logujesz się kontem Google, a do skryptów ustawiasz klucz API w zmiennej środowiskowej GEMINI_API_KEY. Zasady Gemini CLI czyta z pliku GEMINI.md w katalogu roboczym; tu również możesz przejąć treść pliku CLAUDE.md. Do uruchomień bez nadzoru służy polecenie gemini -p "Aufgabe". To, którego z trzech narzędzi używasz, zależy przede wszystkim od konta, które i tak już masz: sposób pracy na serwerze jest we wszystkich trzech taki sam i możesz korzystać z kilku z nich równolegle.

Alternatywa: agent działa na Twoim komputerze i pracuje przez SSH

Kto nie chce niczego instalować na serwerze, uruchamia Claude Code lub Codex na laptopie i pozwala agentowi wysyłać polecenia przez SSH. Na serwerze umieszcza się w tym celu osobny klucz SSH użytkownika agenta, a w CLAUDE.md zapisuje się zasadę, by wszystkie polecenia serwerowe poprzedzać ciągiem ssh aiagent@server. Przy sporadycznej konserwacji sprawdza się to dobrze, ale dłuższe zadania i zadania cron lepiej uruchamiać bezpośrednio na serwerze. Jak w szczegółach wygląda połączenie przez SSH z osobnym kluczem, aliasem hosta i zatwierdzeniami oraz według jakiej procedury agent wdraża potem zmiany na systemach produkcyjnych, pokazuje relacja z praktyki Połączenie AI z serwerem.

Krok 7: zabezpieczyć serwer i wyznaczyć granice

• Snapshot lub kopia zapasowa przed każdą sesją, w której coś ma zostać zmienione. Strategia kopii zapasowych dla serwerów pokazuje, jak robić to automatycznie.
• Nie wyłączaj trybu zatwierdzania. --dangerously-skip-permissions w Claude Code i danger-full-access w Codex są przeznaczone dla jednorazowych maszyn wirtualnych.
• Sekrety poza zasięgiem. Użytkownik agenta nie może mieć dostępu do odczytu plików .env, haseł do baz danych ani danych klientów. To, co agent przeczyta, trafia do dostawcy.
• Limit kosztów dla każdego klucza API ustaw w konsoli dostawcy.
• Możliwość prześledzenia zmian: zainstaluj etckeeper, żeby każda zmiana w /etc trafiała do Git, i przechowuj podsumowania agenta.
• W ruchu przychodzącym nic się nie zmienia. Oba narzędzia potrzebują tylko wychodzącego HTTPS. Zapora, Fail2ban i ochrona DDoS hostingodawcy pozostają bez zmian.

Pierwsze zadania: pięć sensownych zleceń

Najlepsze pierwsze zadania to takie, które oznaczają dużo czytania i zero ryzyka. Szybko pokazują, jak dokładnie pracuje agent, i od razu przynoszą korzyść:

• Raport z logów: „Podsumuj błędy i ostrzeżenia z ostatnich 24 godzin, pogrupowane według usług, z prawdopodobną przyczyną.”
• Sprawdzenie usług: „Wypisz wszystkie usługi systemd, które zawiodły, z ostatnim komunikatem błędu i wyjaśnij, co należałoby zrobić w każdym przypadku. Niczego nie zmieniaj.”
• Miejsce na dysku: „Pokaż, które katalogi zajmują najwięcej miejsca, i zaproponuj, co można bezpiecznie usunąć.” Więcej na ten temat w artykule Pełny dysk w Linuksie.
• Aktualizacje: „Które pakiety mają oczekujące aktualizacje bezpieczeństwa i które usługi trzeba będzie potem zrestartować?”
• Serwer WWW: „Sprawdź konfigurację nginx pod kątem błędów i przestarzałych ustawień, a potem omów każde znalezisko.”

Dopiero gdy te analizy są trafne, warto zlecać agentowi zadania, które coś zmieniają, i to najpierw na systemie testowym.

Typowe błędy i rozwiązania

Aktualizacja narzędzi

Claude Code zainstalowany natywnym instalatorem aktualizuje się sam. Narzędzia zainstalowane przez npm zaktualizujesz jednym poleceniem:

npm update -g @openai/codex @google/gemini-cli
codex --version
gemini --version

Nowe wersje od czasu do czasu zmieniają opcje lub ustawienia domyślne. Po aktualizacji przejrzyj listę zmian, zanim pozwolisz, by uruchomienia bez nadzoru działały dalej, i sprawdź najbliższy dzienny raport pod kątem nieprawidłowości.

Podsumowanie

Agenta AI na serwerze skonfigurujesz w godzinę: użytkownik, biała lista sudo, Node.js, narzędzie, zasady. Właściwa praca tkwi w granicach, a te są tu celowo wąskie. Rozszerzaj je krok po kroku, gdy wymaga tego zadanie, nigdy hurtem. Na serwerze root KernelHost lub serwerze dedykowanym nie trzeba do tego niczego odblokowywać: dostęp root, swobodny wybór dystrybucji i połączenia wychodzące są standardem.

Jak agent wdraża potem zmiany na systemach produkcyjnych, z kopią zapasową, ścieżką wycofania i zatwierdzeniami, opisuje relacja z praktyki Połączenie AI z serwerem.

W skrócie

• Claude Code, Codex CLI i Gemini CLI działają na każdym serwerze Linux z Node.js 22, GPU nie jest potrzebne.
• Agent dostaje osobnego użytkownika z białą listą sudo i nigdy nie działa jako root.
• Zasady zapisuje się w CLAUDE.md, AGENTS.md lub GEMINI.md, polecenia odczytowe trafiają na białą listę, a wszystko inne wymaga zatwierdzenia.
• Do zadań cron i skryptów czystym rozwiązaniem jest klucz API z limitem wydatków, a uruchomienia bez nadzoru ograniczają się do odczytu.
• Kopia zapasowa przed każdą sesją, sekrety poza zasięgiem, tryb zatwierdzania włączony.
• Serwery KernelHost od razu zapewniają dostęp root, swobodny wybór dystrybucji i połączenia wychodzące.