Come Eseguire Più Sessioni Claude Code in Parallelo (Senza Perderne il Filo)
Un workflow pratico per eseguire 3 o più sessioni Claude Code e Codex in parallelo senza perdere traccia di quale ha bisogno di te — da un team che lo fa ogni giorno sul lavoro dei clienti.

On this page
Eseguire due sessioni Claude Code sembra un trucco di produttività. Eseguirne cinque sembra radunare gatti. In una giornata normale con un cliente Techsy teniamo aperte tre o quattro sessioni Claude Code e OpenAI Codex insieme: una che rifattorizza una route Next.js, una che scrive test, una in pausa da 20 minuti su un'approvazione che nessuno ha notato. Scrivere codice non è la parte difficile. Sapere quale terminale ha bisogno di un umano, adesso, lo è.
Riepilogo rapido
Per eseguire più sessioni di coding AI in parallelo senza caos: assegna a ogni sessione un compito ristretto, metti ciascuna nel proprio git worktree così non toccano mai gli stessi file, raggruppa le revisioni invece di guardare ogni sessione in diretta, e usa qualcosa che tenga traccia dello stato delle sessioni così sai quale è bloccata. La modalità di fallimento non è mai "troppo output". È una sessione finita o bloccata che resta silenziosa mentre aspetti quella sbagliata.
Perché una sessione è diventata quattro
Una singola sessione agente ha tempi morti. Pianifica, modifica, esegue una suite di test, aspetta un'installazione lenta. Mentre lavora, tu resti lì seduto. La mossa ovvia è avviare una seconda sessione su un lavoro non correlato, poi una terza. Due cose rendono tutto questo praticabile nel 2026 che un anno fa erano dolorose: gli agenti mantengono il contesto abbastanza a lungo da gestire un intero task, e i git worktree permettono a ogni sessione di lavorare sul proprio branch in una propria directory.
Il calcolo è semplice. Se ogni sessione è produttiva il 60% del tempo, tre sessioni scaglionate ti tengono più vicino alla piena utilizzazione senza che una blocchi le altre. Ci siamo assestati su tre o quattro come punto in cui il costo di coordinamento inizia a mangiarsi i guadagni.
Il vero problema: le sessioni diventano silenziose, non rumorose
Ecco il fallimento di cui nessuno ti avvisa. Le sessioni parallele non falliscono sommergendoti di output. Falliscono ammutolendosi. Un run finisce e aspetta l'istruzione successiva. Un run si ferma per chiedere "devo eliminare questa migration?" e resta bloccato. Un run raggiunge un rate limit e si blocca. Nessuno di questi casi urla. Li scopri quando passi a quella scheda 15 minuti dopo e ti rendi conto che la sessione che pensavi stesse lavorando è rimasta inattiva per tutto il tempo.
Da tre sessioni in su, la risorsa scarsa non è la potenza di calcolo. È la tua attenzione, e in particolare sapere dove indirizzarla dopo.
Un workflow che regge oltre le tre sessioni
Ecco il setup che usiamo sul lavoro reale:
- Un compito per sessione. "Rifattorizza il modulo auth" è una sessione. "Migliora il codebase" non lo è. Uno scope ristretto è ciò che ti permette di lasciare una sessione da sola e fidarti del suo output più tardi.
- Un git worktree per sessione.
git worktree add ../feature-x feature-xdà a ogni agente la propria directory e il proprio branch. Due sessioni che modificano lo stesso file è il modo più veloce per perdere un pomeriggio in conflitti di merge. - Scagliona gli avvii. Avvia le sessioni a qualche minuto di distanza così raggiungono il loro momento "serve una revisione" in orari diversi, non tutte insieme.
- Raggruppa le revisioni. Non fare da balia. Lascia lavorare le sessioni, poi rivedi due o tre diff in un unico passaggio concentrato. Il context-switching a ogni piccolo passo è dove la produttività si perde davvero.
- Conosci lo stato delle sessioni senza controllare. Questo è il pezzo che quasi tutti saltano, ed è quello che fa sopravvivere gli altri quattro al contatto con una giornata piena. Se hai già scritto uno
SKILL.md, sai già che la disciplina ripaga; qui vale lo stesso. Guarda la nostra guida alla scrittura di uno skill Claude per il workflow più ampio, e la libreria Techsy per le automazioni su cui facciamo affidamento.
Vedere lo stato delle sessioni a colpo d'occhio
I passi da uno a quattro sono abitudini. Il passo cinque richiede uno strumento, perché non puoi tenere d'occhio cinque terminali e fare anche deep work. Vuoi qualcosa che osservi le sessioni e ti dica quale ha bisogno di te, così non stai a girare tra le schede in un loop continuo.
Trasparenza: Agent Island è un partner di Techsy, e il link in questa sezione è sponsorizzato.
Agent Island è un companion di stato gratuito e open-source per Claude Code e OpenAI Codex su macOS e Windows. Funziona in locale e mostra, a colpo d'occhio, se ogni sessione supportata è al lavoro, in attesa di input, terminata, bloccata o limitata da un rate limit, e può avvisarti quando una sessione ha bisogno di input. Legge lo stato delle sessioni sulla tua stessa macchina: non serve creare un account Agent Island, non c'è telemetria di prodotto, e i dati delle tue sessioni non vengono caricati su Agent Island. Il codice sorgente è licenziato MIT e disponibile su GitHub. Per essere chiari sul perimetro: non è un agente di coding AI, non è un IDE, e non è un servizio di monitoraggio hosted. È uno strato di stato che si affianca agli strumenti che già usi e risponde bene a una sola domanda: quale sessione ha bisogno di me adesso.
Quando non eseguire sessioni parallele
Il parallelismo non è gratis. Evitalo quando:
- Il lavoro è strettamente accoppiato. Se ogni modifica tocca gli stessi file core, le sessioni si scontreranno tra loro. Esegui una sola sessione.
- Stai ancora esplorando. Il lavoro di design iniziale richiede tutta la tua attenzione su un solo filo, non quattro mezzo formati.
- Non riesci a rivedere allo stesso ritmo con cui generi. Quattro sessioni che producono diff che non leggi mai non è velocità. È un backlog con passaggi in più e più rischio.
Due sessioni ben gestite battono però cinque di cui hai perso il controllo.
Come lo fa il team Techsy
Sui progetti dei clienti ci fermiamo a quattro sessioni, un compito ciascuna, ognuna nel proprio worktree, revisionate a gruppi circa ogni mezz'ora. Il cambiamento che ha fatto la differenza più grande non è stato un modello più veloce. È stato eliminare il bisogno di controllare. Quando una sessione annuncia da sola il proprio stato, "quale è bloccata" smette di essere una domanda che ti porti in testa, e tutto smette di sembrare radunare gatti. Quel singolo cambiamento è ciò che ci ha portato da "due sessioni è il mio limite" a eseguirne quattro senza ansia.
Domande frequenti
Quante sessioni Claude Code posso eseguire contemporaneamente?
Tecnicamente tante quante ne permettono la tua macchina e i rate limit. In pratica, la maggior parte degli sviluppatori si ferma a tre o quattro prima che l'overhead di coordinamento annulli il beneficio. Inizia con due, aggiungi una terza solo quando revisionare quel numero di diff ti risulta comodo.
Le sessioni parallele condividono contesto o memoria?
No. Ogni sessione Claude Code o Codex ha la propria finestra di contesto e la propria conversazione. Questo isolamento è una feature: è per questo che puoi assegnare loro compiti non correlati. Ed è anche per questo che un git worktree per sessione conta, così anche le modifiche ai file restano isolate.
A cosa serve un git worktree in questo caso?
Un worktree dà a ogni sessione la propria directory di lavoro e il proprio branch a partire dallo stesso repository. Due agenti che modificano gli stessi file nella stessa directory si sovrascriveranno il lavoro a vicenda. I worktree li tengono fisicamente separati finché non fai il merge.
Come faccio a sapere quando una sessione è in attesa di input?
Senza uno strumento dedicato, non lo sai, finché non controlli. Un companion di stato come Agent Island mostra quali sessioni sono al lavoro, in attesa, terminate, bloccate o limitate da un rate limit, e può avvisarti quando una ha bisogno di input, così non devi girare tra i terminali.
Eseguire più sessioni costa di più?
Usi più capacità del tuo piano e puoi raggiungere i rate limit prima, il che è uno dei motivi per cui le sessioni si bloccano. Scagliona gli avvii e tieni d'occhio gli stati di rate limit invece di assumere che una sessione silenziosa stia ancora lavorando.
Vale la pena eseguire agenti in parallelo per uno sviluppatore da solo?
Sì, una volta che le tue revisioni tengono il passo con ciò che generi. Uno sviluppatore da solo con due sessioni ben delimitate e un modo per vederne lo stato ottiene la maggior parte del beneficio senza il carico di coordinamento di un team intero.
Posso farlo su Windows, o solo su macOS?
Entrambi. Claude Code e Codex funzionano su macOS e Windows, e Agent Island supporta entrambe le piattaforme per lo stato delle sessioni.
Cosa si rompe per primo quando aggiungo troppe sessioni?
Il tuo throughput di revisione. Generare diff è economico; leggerli e fidarsene no. Nel momento in cui il lavoro non revisionato si accumula, non aggiungere altre sessioni e smaltisci prima il backlog.
Informazioni sull'autore
Mert Batur lavora presso Techsy, dove il team costruisce agenti AI, sistemi di automazione e pipeline voice/SDR per clienti B2B. Scrive dello stack di strumenti LLM e delle Claude Skills che il team Techsy usa realmente in produzione. Connettiti su LinkedIn.
