Chiudi il terminale SSH, magari solo per riaprire il laptop più tardi, e trovi Claude Code sparito insieme al contesto su cui stava lavorando. Il motivo è semplice: chiudere la connessione manda un segnale SIGHUP a ogni processo agganciato a quella sessione, Claude Code compreso. Il problema si fa sentire soprattutto se hai spostato il tuo modo di lavorare su una VPS dedicata ad agenti AI invece che sul portatile locale. Ci sono due modi per evitarlo, uno vecchio e universale, uno nuovo e specifico di Claude Code. Vediamoli entrambi, con le differenze reali.
Perché succede
Quando ti disconnetti da SSH, la shell remota riceve un segnale di chiusura e lo propaga a tutti i suoi processi figli, compreso claude se lo hai lanciato normalmente in quella sessione. Non è un bug di Claude Code: è il comportamento standard di qualunque processo lanciato in una shell interattiva SSH senza protezioni.
Metodo 1: tmux, la soluzione universale
tmux crea un terminale virtuale che continua a girare sul server anche quando ti disconnetti, perché il processo non è più figlio della tua sessione SSH ma del server tmux stesso. Funziona con qualsiasi programma da riga di comando, non solo Claude Code.
Installazione, se manca:
sudo apt update && sudo apt install tmuxCrea una sessione con un nome chiaro:
tmux new -s claudeDentro la sessione, avvia Claude Code normalmente:
claudePer scollegarti lasciando tutto attivo: premi Ctrl+B, rilascia, poi premi D. Per rientrare in un secondo momento, da qualunque connessione SSH successiva:
tmux attach -t claudePer vedere se hai già sessioni aperte prima di crearne una nuova:
tmux lsSe ottieni error connecting to /tmp/tmux-0/default (No such file or directory), significa che il server tmux non è ancora partito: puoi creare la sessione senza rischio di sovrascrivere nulla.
Metodo 2: le background session native di Claude Code
Dalla versione 2.1 in poi, Claude Code ha un modo proprio per restare attivo senza tmux: le background session, gestite da un processo “supervisor” separato dal tuo terminale. Non è un dettaglio da poco: mentre tmux tiene viva la sessione del terminale, qui è direttamente Claude Code a girare come processo indipendente, gestito da un supervisor che sopravvive alla chiusura della shell.
Per mandare in background la sessione su cui stai già lavorando, dentro la conversazione digita:
/bgoppure, per lanciarne una nuova direttamente dal terminale senza passare da una sessione interattiva:
claude --bg "controlla i test che falliscono in modo intermittente e sistemali"Claude Code risponde stampando un ID breve e i comandi per gestirla:
backgrounded · 7c5dcf5d · flaky-test-fix
claude agents list sessions
claude attach 7c5dcf5d open in this terminal
claude logs 7c5dcf5d show recent output
claude stop 7c5dcf5d stop this sessionDa lì puoi:
claude agentsper aprire una vista con tutte le sessioni in background, cosa stanno facendo e quali aspettano una tua rispostaclaude attach <id>per rientrare nella conversazione completaclaude logs <id>per vedere l’output recente senza agganciarticlaude stop <id>(oclaude kill) per fermarlaclaude respawn <id>per riavviarla mantenendo la conversazione intatta
Il vantaggio rispetto a tmux: puoi chiudere la shell, aprirne una nuova, persino disconnetterti del tutto, e la sessione continua a lavorare finché ha qualcosa da fare. Se resta ferma e senza nessuno agganciato per circa un’ora, il supervisor ne interrompe il processo per liberare risorse, ma lo stato resta salvato su disco: la prima volta che la riapri, riparte da dove si era fermata. Puoi anche “fissarla” con Ctrl+T dentro claude agents per tenerla sempre attiva.
tmux o background session: quale scegliere
| Aspetto | tmux | Background session (claude --bg) |
|---|---|---|
| Cosa tiene vivo | Il terminale virtuale | Il processo Claude Code stesso, via supervisor |
| Serve installare qualcosa | Sì, il pacchetto tmux | No, è incluso in Claude Code 2.1+ |
| Funziona con altri programmi | Sì, con qualunque comando | No, solo con sessioni Claude Code |
| Vedi l’output in tempo reale scrollando | Sì, come un terminale normale | Solo agganciandoti con claude attach |
| Più sessioni in parallelo | Una per finestra tmux | Vista unica con claude agents su tutte |
| Sopravvive al riavvio della VPS | No | No, ma lo stato resta su disco: riattaccando riparte da dove era |
Se lavori solo con Claude Code, le background session sono la scelta più diretta: zero setup, e claude agents ti dà una vista su tutto quello che hai in corso. Se invece nella stessa sessione remota tieni aperti anche altri processi (un server di sviluppo, un editor da terminale, log da seguire), tmux resta più flessibile perché non è legato a un singolo programma.
E se gestisci più agenti insieme: herdr
tmux e background session risolvono il problema per una sessione. Ma se inizi a far girare più agenti di coding in parallelo sulla stessa VPS, magari Claude Code su un progetto e un altro agente su un secondo, gestirli a mano diventa scomodo. Qui entra herdr, una specie di tmux pensato apposta per gli agenti: un multiplexer che ti mostra lo stato di ognuno (in lavorazione, bloccato, finito, in attesa), tiene le sessioni vive quando chiudi il laptop o l'SSH, ed è un singolo binario in Rust per Linux e macOS.
Una nota che conta se lavori in azienda: herdr è sì open source, ma la licenza non è MIT, è AGPL-3.0 con in più una licenza commerciale. Per uso personale o in laboratorio nessun problema; per un uso aziendale la clausola AGPL va valutata bene prima di costruirci sopra un servizio. È il tipo di strumento che vale la pena conoscere se stai andando verso un setup multi-agente, ma con la compliance a mente. Il progetto è su GitHub.
Il limite di entrambi: nessuno dei due sopravvive a un riavvio della VPS
Sia tmux che le background session di Claude Code perdono il processo attivo se la VPS si riavvia o si spegne. La differenza è cosa succede dopo: con tmux perdi la sessione e basta, devi ricrearla da capo. Con le background session, invece, la conversazione resta segnata come “fallita” nella vista di claude agents, ma il suo stato è salvato su disco: basta aprirla, rispondere o anche solo guardarla, e il supervisor la fa ripartire da dove si era interrotta.
Per un riavvio automatico dopo un reboot della VPS (non della singola sessione, ma dell’intero servizio), serve un livello in più, tipo un servizio systemd che rilancia lo script di avvio a ogni boot, ma è un caso d’uso diverso da quello di “non perdere la sessione quando chiudo SSH” di cui parla questa guida. Se invece ti interessa il dispatch di più sessioni in parallelo per lavorare su task diversi contemporaneamente, ne ho parlato anche a proposito di Claude Opus 4.8 e i subagenti paralleli.
Conclusione
Il problema di partenza, chiudere SSH e vedere Claude Code sparire, si risolve in due modi validi: tmux, che funziona con qualunque programma da terminale ed è la scelta giusta se gestisci più processi insieme, o le background session native (claude --bg, claude agents), pensate apposta per Claude Code e senza bisogno di installare nulla in più. Se questo tipo di workflow ti è nuovo, ho raccontato come lo uso davvero nel pezzo su come ho costruito un software per MSP parlando con l'AI. Per un uso quotidiano su una VPS dedicata a Claude Code, io partirei dalla seconda: meno pezzi da gestire, e una vista unica su tutto quello che hai in corso.
Perché Claude Code si chiude quando disconnetto SSH?
Perché il processo è agganciato alla tua sessione SSH: quando la chiudi, la shell remota manda un segnale SIGHUP a tutti i suoi processi figli, Claude Code compreso, a meno che non lo isoli con tmux o lo mandi in background.
Serve installare qualcosa per usare le background session?
No. Le background session (claude --bg, claude agents) sono incluse in Claude Code 2.1 e successive, non richiedono pacchetti aggiuntivi come invece serve per tmux.
Se riavvio la VPS, perdo la conversazione con Claude?
Il processo attivo sì, si interrompe. Ma con le background session lo stato resta salvato su disco: quando riapri la sessione con claude attach, riparte da dove si era fermata invece di andare persa del tutto.
Posso avere più sessioni Claude Code attive insieme sulla stessa VPS?
Sì. Con claude agents vedi tutte le sessioni in background in un’unica schermata, capisci quali stanno lavorando, quali aspettano una risposta e quali hanno finito, senza dover aprire una finestra per ciascuna.
Meglio tmux o le background session native?
Se sulla VPS lavori solo con Claude Code, le background session sono più dirette e non richiedono setup. Se invece tieni aperti anche altri processi nella stessa sessione remota, tmux resta più flessibile perché non è legato a un singolo programma.
Per la stesura della guida sono state consultate la documentazione ufficiale di Claude Code su CLI e background session.
Claude Code Docs
CLI reference di Claude Code
Riferimento ufficiale a tutti i comandi e flag della CLI, inclusi --resume, --continue, --bg e --permission-mode.
Claude Code Docs
Gestire più agenti con agent view
Documentazione ufficiale sulle background session, il processo supervisor e come dispatchare, monitorare e riprendere sessioni Claude Code senza terminale agganciato.
Apri fonteSe vuoi seguire le prossime guide operative su Claude Code e agenti AI prima che le racconti altrove, iscriviti alla newsletter settimanale su francescogruner.it.
Nuovo su Google
Aggiungi francescogruner.it come fonte preferita
Se leggi spesso i miei articoli su AI, automazione e tecnologia, ora puoi dire a Google che vuoi vedere più spesso i contenuti di francescogruner.it tra le notizie.
