Chi ha già aperto una seconda sessione di Claude Code sullo stesso repository, per poi ritrovarsi davanti a un groviglio di modifiche accantonate e fusioni incomplete, non ha bisogno di un prompt migliore: ha bisogno di una directory di lavoro separata per ogni sessione. Anthropic mette a disposizione proprio per questo l'opzione --worktree (documentazione ufficiale), e nella prima metà del 2026 tutti i principali concorrenti hanno adottato lo stesso principio. Noi lavoriamo così ogni giorno sulla nostra base di codice editoriale multilingue. Di seguito trova la sequenza che funziona, il problema di ambiente di cui nessuno la avverte e il limite che nessuno strumento rimuove.
Che cosa entra davvero in conflitto quando gli agenti lavorano in parallelo
Dietro la formula «gli agenti si pestano i piedi» si nascondono tre conflitti distinti, ciascuno con una soluzione propria.
Le modifiche ai file. Due sessioni che modificano lo stesso file nella stessa directory producono esattamente il conflitto di merge la cui risoluzione richiede più tempo dell'attività iniziale (Developers Digest). Un cambio di ramo in un terminale altera nel frattempo, senza preavviso, i file su cui sta lavorando una sessione in un altro.
L'ambiente. Una seconda directory non contiene né .env né le dipendenze installate, e spesso ha la stessa porta impostata in modo fisso della prima. L'agente finisce così per analizzare la sua configurazione locale anziché il ticket.
L'attenzione. Dieci agenti producono dieci diff. È il conflitto che nessuna opzione risolve, ed è quello che determina quanti agenti convenga davvero avviare.
Passaggio 1: assegnare a ogni sessione una directory di lavoro propria
Un git worktree è una directory autonoma, con i propri file e il proprio ramo, che condivide cronologia e repository remoto con la copia principale. Claude Code la crea e avvia la sessione direttamente al suo interno:
claude --worktree feature-auth
Per impostazione predefinita la directory viene creata in .claude/worktrees/feature-auth/ nella radice del repository, su un nuovo ramo chiamato worktree-feature-auth. Ripetendo lo stesso comando con un altro nome in un secondo terminale si ottiene una seconda sessione isolata. Omettendo il nome ne viene generato uno, per esempio bright-running-fox (documentazione ufficiale).
Tenga queste directory fuori dallo stato della copia principale:
echo ".claude/worktrees/" >> .gitignore
Le esecuzioni interattive presuppongono che la directory sia considerata attendibile. Se non ha mai avviato Claude Code in quella posizione, lo avvii una volta senza opzioni per accettare la finestra di conferma, altrimenti il comando termina con un errore. Le esecuzioni non interattive con -p saltano del tutto questo controllo.
Per partire da una pull request anziché dal ramo predefinito, indichi il numero preceduto da #, tra virgolette, in modo che la shell non lo interpreti come un commento:
claude --worktree "#1234"
Risultato atteso: git worktree list mostra una voce per ogni sessione attiva, ciascuna sul proprio ramo worktree-*, e nessuna sessione vede le modifiche delle altre.
Passaggio 2: portare con sé l'ambiente che la directory non eredita
È il passaggio che fallisce per primo, e fallisce in silenzio. Una nuova directory di lavoro è una copia pulita: i file ignorati da Git non la seguono.
❌ Prima. Avvia claude --worktree feature-auth, l'agente esegue la suite di test e questa fallisce per variabili d'ambiente mancanti. L'agente impiega poi la propria finestra di contesto a diagnosticare la configurazione locale invece di svolgere l'attività.
✅ Dopo. Aggiunga un file .worktreeinclude nella radice del progetto. Segue la sintassi di .gitignore e vengono copiati soltanto i file che corrispondono a un criterio e sono ignorati da Git, così i file versionati non vengono mai duplicati:
.env
.env.local
config/secrets.json
Lo stesso comando claude --worktree feature-auth parte ora con un ambiente funzionante, e questo vale per ogni directory creata da Claude Code (documentazione ufficiale). Le dipendenze vanno comunque installate nella nuova copia: ne faccia la prima istruzione impartita all'agente oppure esegua personalmente lo script di configurazione del progetto.
Una impostazione predefinita merita di essere modificata. Le nuove directory derivano dal ramo predefinito del repository remoto, il che di norma è corretto. Quando invece distribuisce agenti su lavoro che esiste solo in locale, conviene partire dal proprio HEAD attuale:
{
"worktree": {
"baseRef": "head"
}
}
Situazione critica da tenere d'occhio: mantenendo l'impostazione predefinita, una directory che dovrebbe partire da un ramo non ancora inviato al remoto parte silenziosamente da main, e l'agente sembra perdere un lavoro che in realtà non è mai andato perduto.
Passaggio 3: scegliere la modalità di coordinamento adatta al lavoro
L'isolamento non è ancora orchestrazione. Anthropic documenta quattro modi distinti di far lavorare Claude Code in parallelo, e sbagliare modalità è un errore frequente e costoso (documentazione ufficiale):
| Modalità | Che cosa offre | Quando conviene |
|---|---|---|
| Ausiliari delegati | Le attività secondarie girano in un contesto proprio dentro una sessione e restituiscono una sintesi | Una ricerca o un registro voluminoso inonderebbe la conversazione principale |
Vista degli agenti (claude agents) | Una sola schermata per avviare e sorvegliare sessioni in background | Ha attività indipendenti e preferisce ricontrollare più tardi |
| Squadre di agenti | Sessioni coordinate con elenco di attività condiviso e comunicazione diretta, guidate da un'istanza responsabile | Vuole che il lavoro venga suddiviso, assegnato e mantenuto sincronizzato al posto suo |
| Flussi dinamici | Uno script che avvia molti ausiliari e ne confronta i risultati | Una verifica dell'intera base di codice o una migrazione di diverse centinaia di file |
È proprio qui che si nasconde la trappola. La vista degli agenti sposta automaticamente ogni sessione avviata in una directory propria; le squadre di agenti no. Attivando le squadre e saltando la ripartizione dei file si reintroduce esattamente il conflitto eliminato al passaggio 1.
Non appena più sessioni girano senza sorveglianza, serve un punto in cui il loro stato diventi visibile: è esattamente la tesi che abbiamo sostenuto parlando di una cabina di regia per gli agenti.
Per le definizioni di agenti in .claude/agents/, renda permanente l'isolamento con una sola riga di intestazione:
---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---
Apply the requested refactor across every affected file, then run the tests
and report the results.
Passaggio 4: isolare in un ambiente protetto le sessioni che non sorveglia più
Le directory di lavoro isolano i file all'interno del repository. Non isolano nient'altro sulla macchina, e Claude Code non sostiene il contrario. La cosa diventa rilevante nel momento in cui gli agenti girano senza richieste di autorizzazione.
Gli ambienti protetti di Docker assegnano a ogni agente un ambiente eliminabile:
sbx run claude ~/my-project
Il comando di avvio predefinito all'interno di un ambiente protetto è claude --dangerously-skip-permissions, scelta difendibile proprio perché il danno possibile resta circoscritto a un contenitore e non tocca la sua postazione (documentazione Docker). La modalità clone va oltre: l'agente lavora in un clone Git privato all'interno dell'ambiente protetto, mentre il repository sull'host viene montato in sola lettura.
sbx run --clone claude
Due vincoli documentati le si presenteranno (guida all'uso di Docker):
- La modalità clone si fissa al momento della creazione. Convertire un ambiente esistente significa rimuoverlo e ricrearlo.
- La modalità clone viene rifiutata da qualsiasi directory di lavoro diversa da quella principale, poiché il montaggio in sola lettura non riesce a risolvere il file
.gitdi quella directory. La esegua quindi dalla copia principale.
Gli ambienti protetti non ereditano inoltre la configurazione a livello di utente contenuta in ~/.claude: al loro interno è visibile soltanto la configurazione della directory di progetto. Gli agenti che dipendono dalle sue impostazioni personali si comportano lì in modo diverso, e accorgersene a metà attività è più fastidioso che saperlo in anticipo.
Passaggio 5: fissare il limite di concorrenza in base alla capacità di revisione
Ormai ogni fornitore propone lo stesso meccanismo di isolamento. Cursor 3.0 ha ritirato Composer a favore di una finestra degli agenti che li distribuisce su directory isolate e connessioni SSH (Level Up Coding). L'applicazione desktop di GitHub Copilot, presentata alla conferenza Microsoft Build il 2 giugno 2026, assegna a ogni sessione parallela una directory propria (Digital Applied), e il 9 luglio 2026 GitHub ha reso le sessioni parallele disponibili a tutti in VS Code (TechTimes). Gli orchestratori desktop sono confluiti sullo stesso modello: un agente per directory, con un diff da approvare (Parallel Code). Nelle guide sul campo il lavoro sequenziale viene ormai presentato come un vincolo dello strumento e non dell'attività (le directory di lavoro spiegate).
Quando tutti gli strumenti risolvono l'isolamento allo stesso modo, l'isolamento smette di essere un elemento distintivo. Resta la sua capacità di revisione.
Noi ci limitiamo a quattro sessioni contemporanee per repository, poiché oltre quella soglia il tempo speso a revisionare e integrare i risultati costa più di quanto la parallelizzazione faccia risparmiare. Il decimo agente non è frenato da Git. È frenato dal fatto che dieci diff che arrivano insieme vengono revisionati peggio di tre che si presentano uno dopo l'altro, e un diff di un agente revisionato male costa più di un'attività mai iniziata.
È la stessa logica di costo applicata alla fatturazione dei modelli a token: il prezzo indicato raramente determina l'importo finale.
Per lo stesso motivo continuiamo a sostenere la scelta dell'agente più essenziale quando l'attività non richiede lo strumento più completo.
Ecco come individuare il proprio numero: avvii tre agenti per una settimana e misuri quanto tempo ciascun diff resta in attesa prima che una persona lo apra. Se l'attesa si allunga, non sta aggiungendo capacità ma coda. Più sessioni contemporanee moltiplicano inoltre il consumo di token, per cui la curva dei costi sale prima di quella del valore.
Fissi il limite con consapevolezza, isoli in modo pulito al di sotto di esso e gli agenti in parallelo diventeranno una leva reale. Se invece il numero di agenti diventa l'obiettivo, avrà costruito una coda con lavoro aggiuntivo. Per un avvio più concreto cominci dalla nostra introduzione onesta per chi non sviluppa; se desidera che l'impianto venga progettato sulla sua base di codice e non su una dimostrazione, il nostro team di ingegneria svolge esattamente questo lavoro.
Domande frequenti
Servono directory separate già con due agenti? Sì, se entrambi modificano file. Due sessioni di Claude Code nella stessa copia entrano in conflitto sui cambi di ramo e sugli accantonamenti, a prescindere dal numero (Developers Digest). Il costo si riduce a un'opzione, quindi non esiste una soglia che giustifichi l'attesa.
Che fine fa la directory di lavoro quando una sessione termina?
All'uscita Claude Code verifica la presenza di file modificati, file non tracciati e nuovi commit. Le sessioni pulite e senza nome vengono rimosse automaticamente; se la directory contiene lavoro, le viene posta una domanda. Le esecuzioni non interattive con -p non fanno mai pulizia: le rimuova con git worktree remove (documentazione ufficiale).
Le squadre di agenti sostituiscono le directory di lavoro? No. Le squadre coordinano il lavoro, le directory isolano i file. Le squadre sono sperimentali, disattivate per impostazione predefinita, e non isolano esplicitamente i membri, per cui la responsabilità sui file va ripartita manualmente (documentazione ufficiale).
Serve un ambiente protetto o basta una directory di lavoro? Una directory isola soltanto i file del repository. Se gli agenti girano senza richieste di autorizzazione, usi un ambiente protetto affinché il danno possibile resti circoscritto a un contenitore (documentazione Docker). Per sessioni sorvegliate su un repository affidabile la directory è sufficiente.
Quanti agenti in parallelo sono troppi? Il limite sta nella capacità di revisione, non negli strumenti. Se settimana dopo settimana i diff attendono più a lungo prima che una persona li apra, ha superato la soglia. Noi ne usiamo quattro per repository e misuriamo l'attesa anziché il numero di agenti.
Fonti
- Sessioni parallele con le directory di lavoro — documentazione di Claude Code — Anthropic, aggiornata al 17/07/2026
- Far lavorare gli agenti in parallelo — Anthropic, aggiornata al 18/07/2026
- Claude Code negli ambienti protetti di Docker — Docker, aggiornata al 15/07/2026
- Ambienti protetti Docker: uso e modalità clone — Docker, aggiornata al 15/07/2026
- GitHub chiude il ciclo agentico in VS Code — TechTimes, 09/07/2026
- Parallel Code a confronto con Conductor — Parallel Code, 15/06/2026
- Le directory di lavoro di Git spiegate per gli agenti paralleli — bri, 14/06/2026
- Il manuale pratico 2026 per gli agenti in parallelo — Developers Digest, 10/06/2026
- L'applicazione desktop GitHub Copilot — Digital Applied, 06/06/2026
- Panoramica quotidiana sull'IA del 22 maggio 2026 — Level Up Coding, 22/05/2026