Installare Claude Code e ChatGPT Codex su un server Linux: passo dopo passo

Questa guida ti porta da un server Debian o Ubuntu appena installato a un agente IA operativo, che analizza i log, controlla le configurazioni ed esegue i compiti di manutenzione. Configuriamo Claude Code (Anthropic) e Codex CLI (OpenAI, lo strumento a riga di comando dietro ChatGPT), entrambi con un utente dedicato dai permessi limitati, e mostriamo Gemini CLI (Google) come terza possibilità. Tutti i comandi sono stati provati su un server root KVM di KernelHost con Debian 13 e Ubuntu 24.04. Che cosa sia in generale un server gestito da IA e quali architetture esistano lo spiega l'articolo Server gestito da IA: collegare agenti in sicurezza.

Aggiornato a settembre 2026. Gli strumenti evolvono rapidamente; in caso di dubbio verifica le opzioni con claude --help, codex --help o gemini --help.

Requisiti

• Un server root con Debian 12 o 13 oppure Ubuntu 22.04 o 24.04 e accesso root via SSH. Su AlmaLinux e Rocky Linux i passaggi sono gli stessi, solo che il comando per i pacchetti è dnf invece di apt.
• Messa in sicurezza di base già fatta: accesso SSH con chiave, firewall, aggiornamenti di sicurezza automatici. La checklist per nuovi server root copre tutti questi punti.
• Un account Anthropic (Claude Pro, Max o Team) o una chiave API, un account ChatGPT (Plus, Pro o Team) o una chiave API OpenAI. Se vuoi configurare un solo strumento, te ne basta uno.
• HTTPS in uscita verso api.anthropic.com e api.openai.com. Sui server KernelHost è così di serie; se usi un tuo firewall restrittivo, deve consentirlo.

Quale server basta per un agente IA?

Per un agente IA il server non ha bisogno di hardware particolare né di una GPU, perché il modello linguistico gira presso il fornitore. Sul server girano solo lo strumento a riga di comando e Node.js, che durante una sessione occupano insieme di solito poche centinaia di megabyte di memoria. Per un server su cui gira poco altro bastano 2 vCPU e 4 GB di RAM. Se il server ospita anche siti web, database o game server, prevedi per l'agente una riserva di circa 1 GB di memoria. Un server root KVM di KernelHost è pronto in circa 30 secondi, viene fatturato in modalità PrePaid senza durata minima ed è quindi adatto anche come sistema di test su cui provare l'agente per cominciare.

Passo 1: creare un utente dedicato e limitare sudo

L'agente non gira mai come root. Riceve un account proprio e, tramite un'allowlist sudo, esattamente i comandi di cui ha bisogno. Inizia con pochi comandi di sola lettura ed estendi l'elenco quando un compito lo richiede davvero.

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

L'ultima riga verifica la sintassi. Un errore in un file sudoers può bloccare sudo per tutti, per questo la verifica non va mai saltata. --disabled-password fa sì che nessuno possa accedere come aiagent con una password; più avanti entrerai nell'account con sudo -iu aiagent. Come funzionano in generale gli utenti sudo lo spiega l'articolo Creare un utente sudo su Linux.

Permessi di scrittura mirati invece di un editor via sudo

Se l'agente deve modificare file in /etc, non concedergli nano via sudo (così potrebbe modificare qualsiasi file, compreso /etc/sudoers), ma lavora con un gruppo e permessi di scrittura mirati, per esempio setfacl -m u:aiagent:rw /etc/nginx/sites-available/meine-seite.conf. Per cominciare è più che sufficiente che l'agente proponga le modifiche e che sia tu ad applicarle.

Lo stesso vale per i comandi con caratteri jolly nell'allowlist. /usr/bin/tail * consente all'agente di leggere qualsiasi file a cui root ha accesso, compresi i file con credenziali di accesso. Chi non lo desidera scrive per esteso i percorsi consentiti, per esempio /usr/bin/tail -n 200 /var/log/nginx/error.log.

Passo 2: installare Node.js 22

Entrambi gli strumenti girano con Node.js. Claude Code richiede almeno la versione 18, Codex CLI almeno la 22, perciò installiamo la 22 LTS. I repository di Debian 12 forniscono una versione troppo vecchia; NodeSource fornisce quella attuale:

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

Alternativa senza privilegi di root: nvm

Chi non vuole eseguire con privilegi di root script scaricati da internet usa nvm nella home dell'utente agente; in questo modo i privilegi di root non servono affatto. Il comando di installazione di nvm lo prendi dal README del progetto, dopodiché bastano tre righe:

nvm install 22
nvm alias default 22
node --version

Dettagli e altri metodi si trovano nella guida all'installazione di Node.js su Debian.

Passo 3: installare Claude Code ed effettuare l'accesso

Da qui in poi lavoriamo nell'account dell'agente:

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

L'installer nativo colloca Claude Code in ~/.local/bin e si mantiene aggiornato da solo. In alternativa puoi usare npm con npm install -g @anthropic-ai/claude-code; se l'installazione fallisce con EACCES, trovi la soluzione nella sezione sulla risoluzione dei problemi più avanti.

Accesso su un server senza browser

Al primo avvio di claude lo strumento ti chiede di effettuare l'accesso. Con un account Claude di norma apre il browser; su un server senza browser mostra invece un indirizzo e un codice, che confermi sul portatile o sullo smartphone. Da quel momento l'accesso vale per questo utente su questo server, finché non ti disconnetti.

Chiave API per script e cron job

Per script e cron job una chiave API è la scelta migliore:

echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> ~/.bashrc
chmod 600 ~/.bashrc
source ~/.bashrc
claude -p "Rispondi solo con OK" 

In questo modo la chiave si trova solo nella home dell'utente agente, che gli altri utenti non possono leggere. Creala nella console Anthropic con un limite di spesa mensile: così una sessione che sfugge di mano non può diventare costosa. Non scrivere mai la chiave vera e propria in un compito per l'agente né in un file che l'agente deve visualizzare.

Passo 4: configurare Claude Code per il server

Il file di regole CLAUDE.md

All'avvio Claude Code legge un file CLAUDE.md nella directory corrente. Contiene le regole valide per ogni sessione. Crea nella home dell'agente una directory di lavoro con questo file:

mkdir -p ~/server && cd ~/server
cat > CLAUDE.md <<'EOF'
# Regole per questo server
- Questo è un server di produzione (Debian 13, nginx, PHP-FPM, MariaDB).
- I comandi di sola lettura (journalctl, systemctl status, tail, df, ss) sono consentiti in qualsiasi momento.
- Prima di ogni comando di scrittura spiegare brevemente che cosa modifica e attendere l'approvazione.
- Mai rimuovere pacchetti, mai cancellare file sotto /var/lib, mai creare o eliminare utenti.
- Mai ripetere password, chiavi o dati dei clienti nell'output.
- Alla fine di ogni compito fornire un riepilogo in tre frasi.
EOF

Il file cresce nel tempo. Ogni volta che l'agente fa qualcosa in modo diverso da come vuoi tu, aggiungi la correzione come nuova regola. Dopo qualche settimana il file rispecchia abbastanza fedelmente il modo di lavorare sul tuo server.

L'allowlist in settings.json

A questo si aggiunge un'allowlist degli strumenti, così Claude Code esegue i comandi di sola lettura senza chiedere e chiede conferma per tutto il resto. Il file ~/.claude/settings.json vale per l'utente:

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

La deny list è una rete di sicurezza in più, non un muro: un comando si può scrivere in molti modi. Il vero confine lo traccia l'allowlist sudo del passo 1, perché ciò che l'utente non può fare non può farlo nemmeno l'agente.

Il primo compito in modalità interattiva

Ora il primo compito, in modalità interattiva:

cd ~/server && claude
> Riassumi gli errori di journalctl delle ultime 24 ore e indica le tre cause più frequenti.

Senza supervisione con un cron job

E lo stesso compito senza supervisione, per esempio come cron job quotidiano alle 7, il cui risultato arriva via email:

0 7 * * * cd /home/aiagent/server && /home/aiagent/.local/bin/claude -p "Riassumi errori e avvisi di journalctl delle ultime 24 ore. Indica servizio, orario e causa probabile." --allowedTools "Bash(sudo journalctl:*)" 2>&1 | mail -s "Rapporto giornaliero del server" admin@example.com

L'opzione -p avvia Claude Code senza sessione interattiva, --allowedTools limita gli strumenti esattamente a ciò che serve all'esecuzione. Le azioni di scrittura non vanno nelle esecuzioni non presidiate. Come si configurano in generale i cron job lo spiega l'articolo Configurare un cron job su Linux.

Passo 5: installare Codex CLI (ChatGPT) ed effettuare l'accesso

Installazione e accesso

Codex CLI è lo strumento di OpenAI che porta sulla riga di comando i modelli dietro ChatGPT. L'installazione avviene nello stesso account utente:

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

L'accesso avviene con l'account ChatGPT (Plus, Pro o Team): avvia codex, scegli «Sign in with ChatGPT» e apri l'indirizzo mostrato su un dispositivo con browser. Per gli script imposta invece una chiave API della piattaforma OpenAI:

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

Sandbox e modalità di approvazione in config.toml

Codex ha una propria sandbox e una modalità di approvazione. Entrambe si definiscono in ~/.codex/config.toml; per un server di produzione questa combinazione è sensata:

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

workspace-write consente scritture solo nella directory di lavoro corrente, on-request fa sì che l'agente chieda il permesso per tutto ciò che va oltre. Il livello danger-full-access annulla entrambe le restrizioni e non va usato su un sistema di produzione.

Regole in AGENTS.md

Codex legge regole come quelle di CLAUDE.md da un file AGENTS.md nella directory di lavoro; puoi usare lo stesso contenuto:

cp ~/server/CLAUDE.md ~/server/AGENTS.md
cd ~/server && codex "Verifica se tutti i servizi systemd abilitati sono in esecuzione ed elenca quelli falliti con l'ultimo messaggio di errore."

Per le esecuzioni non presidiate c'è codex exec "Aufgabe", l'equivalente di claude -p.

Passo 6: Gemini CLI come terza possibilità

Gemini CLI è lo strumento a riga di comando di Google e funziona secondo lo stesso principio. Anche questo gira con Node.js e si installa nello stesso account utente:

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

Al primo avvio di gemini accedi con un account Google; per gli script imposti una chiave API nella variabile d'ambiente GEMINI_API_KEY. Gemini CLI legge le regole da un file GEMINI.md nella directory di lavoro, e anche qui puoi riprendere il contenuto di CLAUDE.md. Le esecuzioni non presidiate si avviano con gemini -p "Aufgabe". Quale dei tre strumenti usare dipende soprattutto dall'account che hai già: sul server il modo di lavorare è lo stesso per tutti e tre, e puoi usarne più di uno in parallelo.

Alternativa: l'agente gira sul tuo computer e lavora via SSH

Chi non vuole installare nulla sul server avvia Claude Code o Codex sul portatile e lascia che l'agente invii i comandi via SSH. Per questo il server riceve una chiave SSH dedicata dell'utente agente, e in CLAUDE.md c'è la regola di anteporre ssh aiagent@server a tutti i comandi per il server. Per la manutenzione occasionale funziona bene, ma i compiti più lunghi e i cron job girano meglio direttamente sul server. Come si presenta nel dettaglio il collegamento SSH con chiave dedicata, alias host e approvazioni, e quale procedura segue poi l'agente per il deploy sui sistemi di produzione, lo mostra il resoconto dal campo Collegare l'IA al server.

Passo 7: mettere in sicurezza e fissare limiti

• Snapshot o backup prima di ogni sessione in cui si deve modificare qualcosa. La strategia di backup per server mostra come automatizzarli.
• Lasciare attiva la modalità di approvazione. --dangerously-skip-permissions in Claude Code e danger-full-access in Codex sono pensati per VM usa e getta.
• Segreti fuori portata. L'utente agente non deve poter leggere file .env, password del database e dati dei clienti. Ciò che legge finisce presso il fornitore.
• Limite di spesa per ogni chiave API, da impostare nella console del fornitore.
• Tracciabilità: installare etckeeper, così ogni modifica sotto /etc finisce in Git, e conservare i riepiloghi dell'agente.
• In entrata non cambia nulla. Entrambi gli strumenti hanno bisogno solo di HTTPS in uscita. Firewall, Fail2ban e la protezione DDoS del provider di hosting restano invariati.

I primi compiti: cinque incarichi utili

I primi compiti migliori sono quelli che richiedono molta lettura e non comportano rischi. Mostrano in fretta quanto a fondo lavora l'agente e sono utili fin da subito:

• Rapporto sui log: «Riassumi gli errori e gli avvisi delle ultime 24 ore, raggruppati per servizio, con la causa probabile.»
• Controllo dei servizi: «Elenca tutti i servizi systemd falliti con l'ultimo messaggio di errore e spiega che cosa andrebbe fatto in ciascun caso. Non modificare nulla.»
• Spazio su disco: «Mostra quali directory occupano più spazio e proponi che cosa si può ripulire senza rischi.» Approfondimenti nell'articolo Disco pieno su Linux.
• Aggiornamenti: «Quali pacchetti hanno aggiornamenti di sicurezza in sospeso e quali servizi andranno riavviati dopo?»
• Web server: «Controlla la configurazione di nginx alla ricerca di errori e impostazioni obsolete e spiega ogni punto trovato.»

Solo quando queste analisi sono corrette conviene affidare all'agente compiti di scrittura, e comunque prima su un sistema di test.

Errori tipici e soluzioni

Mantenere aggiornati gli strumenti

Dopo l'installazione con l'installer nativo, Claude Code si aggiorna da solo. Gli strumenti installati tramite npm li porti all'ultima versione con un solo comando:

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

Le nuove versioni cambiano di tanto in tanto opzioni o impostazioni predefinite. Dopo un aggiornamento leggi brevemente le note di rilascio prima di lasciar ripartire le esecuzioni non presidiate, e controlla che il rapporto giornaliero successivo non presenti anomalie.

Conclusione

Un agente IA sul server si configura in un'ora: utente, allowlist sudo, Node.js, strumento, regole. Il vero lavoro sta nei limiti, e qui sono volutamente stretti. Ampliali passo dopo passo quando un compito lo richiede, mai in blocco. Su un server root KernelHost o un server dedicato non c'è nulla da attivare per questo: accesso root, libera scelta della distribuzione e connessioni in uscita sono lo standard.

Come un agente fa poi il deploy sui sistemi di produzione, con backup, rollback e approvazioni, lo descrive il resoconto dal campo Collegare l'IA al server.

In sintesi

• Claude Code, Codex CLI e Gemini CLI girano su qualsiasi server Linux con Node.js 22, senza bisogno di una GPU.
• L'agente riceve un utente dedicato con allowlist sudo e non gira mai come root.
• Le regole stanno in CLAUDE.md, AGENTS.md o GEMINI.md, i comandi di sola lettura vanno nell'allowlist, tutto il resto richiede un'approvazione.
• Per cron job e script la strada pulita è una chiave API con limite di spesa, e le esecuzioni non presidiate restano di sola lettura.
• Backup prima di ogni sessione, segreti fuori portata, modalità di approvazione attiva.
• Sui server KernelHost accesso root, libera scelta della distribuzione e connessioni in uscita sono disponibili di serie.