Instalarea Claude Code și ChatGPT Codex pe un server Linux: pas cu pas

Acest ghid vă conduce de la un server Debian sau Ubuntu proaspăt instalat la un agent AI funcțional, care analizează jurnale, verifică configurații și execută sarcini de întreținere. Configurăm Claude Code (Anthropic) și Codex CLI (OpenAI, instrumentul de linie de comandă din spatele ChatGPT), ambele sub un utilizator propriu cu drepturi limitate, și prezentăm Gemini CLI (Google) ca a treia variantă. Toate comenzile au fost testate pe un server root KVM KernelHost cu Debian 13 și Ubuntu 24.04. Ce este, în principiu, un server gestionat de AI și ce arhitecturi există aflați din articolul Server gestionat de AI: conectarea sigură a agenților AI.

Informații actualizate în septembrie 2026. Instrumentele evoluează rapid; în caz de îndoială, verificați opțiunile cu claude --help, codex --help, respectiv gemini --help.

Cerințe preliminare

• Un server root cu Debian 12 sau 13, respectiv Ubuntu 22.04 sau 24.04, și acces root prin SSH. Pe AlmaLinux și Rocky Linux pașii sunt aceiași, doar comenzile pentru pachete se numesc dnf în loc de apt.
• Securizarea de bază este deja făcută: autentificare SSH cu cheie, firewall, actualizări de securitate automate. Lista de verificare pentru servere root noi acoperă toate aceste puncte.
• Un cont la Anthropic (Claude Pro, Max sau Team) sau o cheie API, un cont ChatGPT (Plus, Pro sau Team) sau o cheie API OpenAI. Dacă doriți să configurați un singur instrument, aveți nevoie doar de unul dintre ele.
• HTTPS de ieșire către api.anthropic.com și api.openai.com. Pe serverele KernelHost acest lucru este asigurat de la livrare, iar un firewall propriu restrictiv trebuie să îl permită.

Ce server este suficient pentru un agent AI?

Un agent AI nu are nevoie pe server de hardware special și nici de GPU, deoarece modelul lingvistic rulează la furnizor. Pe server rulează doar instrumentul de linie de comandă și Node.js, care ocupă împreună, de regulă, câteva sute de megaocteți de memorie în timpul unei sesiuni. Pentru un server pe care nu rulează mare lucru în rest, sunt suficiente 2 vCPU și 4 GB RAM. Dacă serverul găzduiește în paralel site-uri web, baze de date sau servere de jocuri, prevedeți pentru agent o rezervă de aproximativ 1 GB de memorie. Un server root KVM de la KernelHost este livrat în aproximativ 30 de secunde, se facturează PrePaid, fără durată minimă, și se pretează astfel și ca sistem de test, pe care să încercați mai întâi agentul.

Pasul 1: crearea unui utilizator propriu și limitarea sudo

Agentul nu rulează niciodată ca root. Primește un cont propriu și, printr-o listă albă sudo, exact comenzile de care are nevoie. Începeți cu câteva comenzi de citire și extindeți lista atunci când o sarcină o cere cu adevărat.

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

Ultima linie verifică sintaxa. O eroare într-un fișier sudoers poate bloca sudo pentru toți utilizatorii, de aceea verificarea face întotdeauna parte din proces. --disabled-password asigură că nimeni nu se poate autentifica cu parolă ca aiagent; ulterior treceți în acest cont cu sudo -iu aiagent. Cum funcționează, în principiu, utilizatorii sudo explică articolul Crearea unui utilizator sudo în Linux.

Drepturi de scriere țintite în loc de editor prin sudo

Dacă agentul trebuie să modifice fișiere din /etc, nu îi permiteți să folosească nano prin sudo (astfel s-ar putea edita orice fișier, inclusiv /etc/sudoers), ci lucrați cu un grup și cu drepturi de scriere țintite, de exemplu setfacl -m u:aiagent:rw /etc/nginx/sites-available/meine-seite.conf. Pentru început este pe deplin suficient ca agentul să propună modificările, iar dumneavoastră să le aplicați.

Același lucru este valabil pentru comenzile cu caractere wildcard din lista albă. /usr/bin/tail * îi permite agentului să citească orice fișier la care are acces root, inclusiv fișierele cu date de acces. Cine nu dorește acest lucru scrie explicit căile permise, de exemplu /usr/bin/tail -n 200 /var/log/nginx/error.log.

Pasul 2: instalarea Node.js 22

Ambele instrumente rulează pe Node.js. Claude Code necesită cel puțin versiunea 18, Codex CLI cel puțin versiunea 22, de aceea instalăm 22 LTS. Sursele de pachete din Debian 12 livrează o versiune prea veche; NodeSource o livrează pe cea actuală:

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

Alternativă fără drepturi de root: nvm

Cine nu dorește să ruleze cu drepturi de root scripturi descărcate de pe internet folosește nvm în directorul home al utilizatorului agent; în acest fel, totul funcționează complet fără drepturi de root. Comanda de instalare pentru nvm o preluați din fișierul README al proiectului, după care sunt suficiente trei linii:

nvm install 22
nvm alias default 22
node --version

Detalii și alte variante găsiți în ghidul pentru Node.js pe Debian.

Pasul 3: instalarea Claude Code și autentificarea

De aici înainte lucrăm în contul agentului:

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

Instalatorul nativ plasează Claude Code în ~/.local/bin, iar programul se actualizează apoi singur. Alternativ, instalarea se poate face prin npm cu npm install -g @anthropic-ai/claude-code; dacă aceasta eșuează cu EACCES, vă ajută secțiunea de depanare de mai jos.

Autentificarea pe un server fără browser

La prima pornire a comenzii claude, instrumentul solicită autentificarea. Cu un cont Claude deschide în mod normal browserul; pe un server fără browser afișează o adresă și un cod, pe care îl confirmați pe laptop sau pe smartphone. Autentificarea rămâne apoi valabilă pentru acest utilizator pe acest server, până când vă deconectați.

Cheie API pentru scripturi și joburi cron

Pentru scripturi și joburi cron, o cheie API este alegerea mai bună:

echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> ~/.bashrc
chmod 600 ~/.bashrc
source ~/.bashrc
claude -p "Răspunde doar cu OK" 

Astfel, cheia se află doar în directorul home al utilizatorului agent, pe care alți utilizatori nu îl pot citi. Creați-o în consola Anthropic cu o limită lunară de cheltuieli; așa, o sesiune scăpată de sub control nu poate deveni costisitoare. Cheia în sine nu o scrieți niciodată într-o sarcină pentru agent și niciodată într-un fișier pe care acesta urmează să îl afișeze.

Pasul 4: configurarea Claude Code pentru server

Fișierul de reguli CLAUDE.md

La pornire, Claude Code citește un fișier CLAUDE.md din directorul curent. În el se află regulile valabile pentru fiecare sesiune. Creați în directorul home al agentului un director de lucru cu acest fișier:

mkdir -p ~/server && cd ~/server
cat > CLAUDE.md <<'EOF'
# Reguli pentru acest server
- Acesta este un server de producție (Debian 13, nginx, PHP-FPM, MariaDB).
- Comenzile de citire (journalctl, systemctl status, tail, df, ss) sunt permise oricând.
- Înaintea fiecărei comenzi de scriere, explică pe scurt ce modifică și așteaptă aprobarea.
- Nu elimina niciodată pachete, nu șterge niciodată fișiere din /var/lib, nu crea și nu șterge niciodată utilizatori.
- Nu repeta niciodată parole, chei sau date ale clienților în rezultate.
- La sfârșitul fiecărei sarcini, oferă un rezumat în trei propoziții.
EOF

Fișierul crește odată cu experiența. De fiecare dată când agentul face ceva altfel decât doriți, corectura trebuie adăugată ca regulă nouă. După câteva săptămâni, fișierul reflectă destul de exact modul de lucru de pe serverul dumneavoastră.

Lista albă din settings.json

La aceasta se adaugă o listă albă a instrumentelor, astfel încât Claude Code să execute comenzile de citire fără să întrebe și să ceară aprobare pentru orice altceva. Fișierul ~/.claude/settings.json se aplică la nivelul utilizatorului:

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

Lista deny este o plasă de siguranță suplimentară, nu un zid: o comandă poate fi scrisă în multe feluri. Limita propriu-zisă o trasează lista albă sudo din pasul 1, deoarece ce nu are voie să facă utilizatorul nu are voie să facă nici agentul.

Prima sarcină în mod interactiv

Acum prima sarcină, interactiv:

cd ~/server && claude
> Rezumă erorile din journalctl din ultimele 24 de ore și indică cele mai frecvente trei cauze.

Rulare nesupravegheată prin job cron

Și aceeași sarcină fără supraveghere, de exemplu ca job cron zilnic la ora 7, al cărui rezultat sosește prin e-mail:

0 7 * * * cd /home/aiagent/server && /home/aiagent/.local/bin/claude -p "Rezumă erorile și avertismentele din journalctl din ultimele 24 de ore. Indică serviciul, ora și cauza probabilă." --allowedTools "Bash(sudo journalctl:*)" 2>&1 | mail -s "Raport zilnic server" admin@example.com

Opțiunea -p pornește Claude Code fără sesiune interactivă, iar --allowedTools limitează instrumentele exact la ce are nevoie rularea respectivă. Acțiunile de scriere nu își au locul în rulările nesupravegheate. Cum se configurează, în principiu, joburile cron aflați din articolul Configurarea unui job cron în Linux.

Pasul 5: instalarea Codex CLI (ChatGPT) și autentificarea

Instalare și autentificare

Codex CLI este instrumentul OpenAI care aduce în linia de comandă modelele din spatele ChatGPT. Instalarea se face în același cont de utilizator:

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

Autentificarea se face cu contul ChatGPT (Plus, Pro sau Team): porniți codex, alegeți „Sign in with ChatGPT” și deschideți adresa afișată pe un dispozitiv cu browser. Pentru scripturi setați în schimb o cheie API de pe platforma OpenAI:

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

Sandbox și mod de aprobare în config.toml

Codex vine cu propriul sandbox și cu un mod de aprobare. Ambele se stabilesc în ~/.codex/config.toml; pentru un server de producție, această combinație este potrivită:

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

workspace-write permite scrierea doar în directorul de lucru curent, iar on-request îl face pe agent să ceară permisiunea pentru tot ce depășește acest cadru. Nivelul danger-full-access le anulează pe amândouă și nu își are locul pe un sistem de producție.

Reguli în AGENTS.md

Codex citește reguli precum cele din CLAUDE.md dintr-un fișier AGENTS.md aflat în directorul de lucru; puteți folosi același conținut:

cp ~/server/CLAUDE.md ~/server/AGENTS.md
cd ~/server && codex "Verifică dacă toate serviciile systemd activate rulează și listează-le pe cele eșuate împreună cu ultimul mesaj de eroare."

Pentru rulările nesupravegheate există codex exec "Aufgabe", echivalentul lui claude -p.

Pasul 6: Gemini CLI ca a treia variantă

Gemini CLI este instrumentul de linie de comandă de la Google și funcționează pe același principiu. Rulează tot pe Node.js și se instalează în același cont de utilizator:

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

La prima pornire a comenzii gemini vă autentificați cu un cont Google, iar pentru scripturi setați o cheie API în variabila de mediu GEMINI_API_KEY. Gemini CLI citește regulile dintr-un fișier GEMINI.md din directorul de lucru; și aici puteți prelua conținutul fișierului CLAUDE.md. Rulările nesupravegheate le porniți cu gemini -p "Aufgabe". Ce instrument alegeți dintre cele trei depinde în primul rând de contul pe care îl aveți deja: modul de lucru pe server este același la toate trei, iar mai multe dintre ele pot rula în paralel.

Alternativă: agentul rulează pe calculatorul dumneavoastră și lucrează prin SSH

Cine nu dorește să instaleze nimic pe server pornește Claude Code sau Codex pe laptop și lasă agentul să trimită comenzile prin SSH. Pentru aceasta, serverul primește o cheie SSH proprie a utilizatorului agent, iar în CLAUDE.md se află regula ca toate comenzile pentru server să fie precedate de ssh aiagent@server. Pentru întreținerea ocazională, varianta funcționează bine, însă sarcinile mai lungi și joburile cron rulează mai bine direct pe server. Cum arată în detaliu conexiunea SSH, cu cheie proprie, alias de host și aprobări, și după ce procedură face apoi agentul implementări pe sistemele de producție aflați din studiul de caz Conectarea AI la server.

Pasul 7: securizarea și stabilirea limitelor

• Snapshot sau backup înaintea fiecărei sesiuni în care urmează să se modifice ceva. Strategia de backup pentru servere arată cum se face acest lucru automat.
• Lăsați modul de aprobare activ. --dangerously-skip-permissions la Claude Code și danger-full-access la Codex sunt gândite pentru mașini virtuale de unică folosință.
• Secretele rămân în afara accesului. Utilizatorul agent nu trebuie să poată citi fișierele .env, parolele bazelor de date și datele clienților. Ce citește ajunge la furnizor.
• Limită de cost pentru fiecare cheie API, setată în consola furnizorului.
• Trasabilitate: instalați etckeeper, astfel încât fiecare modificare din /etc să ajungă în Git, și păstrați rezumatele agentului.
• La intrare nu se schimbă nimic. Ambele instrumente au nevoie doar de HTTPS de ieșire. Firewallul, Fail2ban și protecția DDoS a furnizorului de hosting rămân neschimbate.

Primele sarcini: cinci solicitări utile

Cele mai potrivite sarcini pentru început sunt cele care presupun multă citire și niciun risc. Ele arată repede cât de temeinic lucrează agentul și aduc imediat un folos:

• Raport din jurnale: „Rezumă erorile și avertismentele din ultimele 24 de ore, grupate pe servicii, cu cauza probabilă.”
• Verificarea serviciilor: „Listează toate serviciile systemd eșuate împreună cu ultimul mesaj de eroare și explică ce ar trebui făcut în fiecare caz. Nu modifica nimic.”
• Spațiu pe disc: „Arată ce directoare ocupă cel mai mult spațiu și propune ce se poate curăța fără risc.” Mai multe detalii găsiți în articolul Disc plin în Linux.
• Actualizări: „Ce pachete au actualizări de securitate în așteptare și ce servicii trebuie repornite după aceea?”
• Server web: „Verifică dacă configurația nginx conține erori sau setări învechite și explică fiecare problemă găsită.”

Abia când aceste analize sunt corecte merită să îi încredințați agentului sarcini de scriere, și anume mai întâi pe un sistem de test.

Erori tipice și soluții

Menținerea instrumentelor la zi

Instalat cu instalatorul nativ, Claude Code se actualizează singur. Instrumentele instalate prin npm le aduceți la zi cu o singură comandă:

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

Versiunile noi modifică uneori opțiuni sau setări implicite. După o actualizare, citiți pe scurt notele de versiune înainte de a lăsa rulările nesupravegheate să continue și verificați dacă următorul raport zilnic conține anomalii.

Concluzie

Un agent AI pe server se configurează într-o oră: utilizator, listă albă sudo, Node.js, instrument, reguli. Munca propriu-zisă constă în stabilirea limitelor, iar acestea sunt trasate aici în mod intenționat strâns. Extindeți-le pas cu pas atunci când o sarcină o cere, niciodată în bloc. Pe un server root KernelHost sau pe un server dedicat nu trebuie activat nimic pentru asta: accesul root, alegerea liberă a distribuției și conexiunile de ieșire sunt standard.

Cum face apoi un agent implementări pe sistemele de producție, cu backup, cale de revenire și aprobări, descrie studiul de caz Conectarea AI la server.

Rezumat

• Claude Code, Codex CLI și Gemini CLI rulează pe orice server Linux cu Node.js 22, fără să aibă nevoie de GPU.
• Agentul primește un utilizator propriu cu listă albă sudo și nu rulează niciodată ca root.
• Regulile se află în CLAUDE.md, AGENTS.md sau GEMINI.md, comenzile de citire intră în lista albă, iar tot restul necesită aprobare.
• Pentru joburi cron și scripturi, calea curată este o cheie API cu limită de cheltuieli, iar rulările nesupravegheate rămân strict de citire.
• Backup înaintea fiecărei sesiuni, secretele în afara accesului, modul de aprobare activ.
• Pe serverele KernelHost, accesul root, alegerea liberă a distribuției și conexiunile de ieșire sunt disponibile de la livrare.