Claude Code Projects è la nuova modalità di Claude Code, in beta dal 17 settembre 2026, in cui descrivi un obiettivo e Claude fa da coordinatore: divide il lavoro, avvia più thread in parallelo nel cloud, controlla i risultati e ti riporta cosa è pronto.
Ogni thread è una sessione cloud completa, con il suo branch e la sua pull request.
Detta così sembra la solita promessa sugli agenti. In realtà cambia una cosa concreta: finora, se volevi tre sessioni in parallelo, il project manager eri tu. Decidevi chi faceva cosa, ripetevi il contesto a ognuna e tornavi a controllare. Con Claude Code Projects quel ruolo passa a Claude.
Lavoro con Claude Code ogni giorno sui progetti dei miei clienti, quindi ho letto l'annuncio e tutta la documentazione con una domanda in testa: quanto costa davvero in termini di piano, e dove si rompe?
Qui trovi requisiti, setup, consumi e limiti, senza il tono da comunicato stampa.
Cos'è Claude Code Projects e cosa cambia rispetto a prima
Un progetto è una conversazione unica e continua. Tu ci incolli dentro un bug, uno stack trace o una lista di task. Claude decide cosa diventa un thread nuovo, cosa va a un thread già aperto su quella zona del codice e a cosa può rispondere subito.
I vecchi Projects di claude.ai erano cartelle: conversazioni e file di riferimento raggruppati. Quelli restano come sono, per ora. Claude Code Projects invece vive dentro Claude Code ed è fatto di quattro pezzi:
- Il coordinatore: la conversazione principale. Riceve le richieste, assegna il lavoro e tiene traccia di ogni thread. Vede quello che i thread riportano, non ogni singolo passo.
- I thread: i lavoratori. Ognuno è una sessione cloud di Claude Code con la sua finestra di contesto, il suo branch e la sua copia del repository. Può dividersi ancora in subagenti quando il compito è grande.
- La memoria condivisa: file che Claude scrive da solo con requisiti, decisioni e trappole del progetto. Ogni thread nuovo li legge all'avvio. Se dici una volta "il rilascio è slittato a venerdì", lo sanno tutti.
- La libreria: i file che carichi tu e quelli prodotti dai thread, tutti in un posto solo.
Se due thread toccano lo stesso codice non c'è magia: la sovrapposizione si risolve come un normale conflitto di merge tra pull request.
Chi può usare Claude Code Projects oggi: i requisiti veri
Molti si fermano a "disponibile per Pro e Max". Per Claude Code Projects i vincoli sono di più, e conviene saperli prima di perdere mezz'ora a cercare un menu che non c'è.
- Piano: beta pubblica su Pro e Max, a rilascio graduale. Parte dagli account che hanno già usato le sessioni cloud e che non hanno progetti esistenti in chat o in Cowork. Team ed Enterprise arrivano dopo.
- Dove si usa: su claude.ai/code, nella scheda Code dell'app desktop e nell'app mobile. Non nel terminale. Il comando
claude projectdella CLI è un'altra cosa e non c'entra. - GitHub: il codice deve stare su github.com. Niente GitLab, Bitbucket o GitHub Enterprise Server. Serve la Claude GitHub App installata sui repository e un account con permesso di push.
- Niente macchina locale: i thread girano solo nel cloud. Database locale, emulatore, API dietro VPN restano fuori. L'esecuzione sulla tua macchina è annunciata come in arrivo a breve.
Se la voce Projects non compare nella sidebar, il rilascio non ha ancora raggiunto il tuo account. C'è una lista d'attesa per chi è su Pro o Max.
Come creare un progetto in Claude Code Projects
La procedura è corta. La parte che fa la differenza è quella dopo la creazione.
- Apri Projects nella sidebar di claude.ai/code o dell'app desktop e scegli New project. In alternativa, da una sessione cloud già avviata usi "Continue as a project".
- Compila il dialog: il nome è obbligatorio, obiettivo e contesto sono opzionali. L'obiettivo è una riga, per esempio tenere la latenza di un'API sotto una certa soglia. Nel contesto aggiungi i repository e gli eventuali file o cartelle Google Drive.
- Scrivi le istruzioni di progetto (fino a 16.000 caratteri): da quale branch partire, come un thread verifica il proprio lavoro, cosa richiede il tuo via libera.
- Manda un solo task piccolo e apri il thread quando finisce, per vedere come riporta e cosa ha fatto sul branch.
- Controlla modello e sforzo dei thread nelle impostazioni, poi chiedi a Claude di proporre i thread prima di avviarli e di tenerne pochi in parallelo.
Nelle istruzioni io metterei sempre tre regole: una pull request in bozza per thread, test e lint eseguiti prima di dichiarare finito, e nessun merge, force push o modifica alla CI senza chiedere.
Una quarta vale oro: se manca un accesso, un segreto o un connettore, il thread deve dirlo e fermarsi, non inventarsi un mock.
Attenzione a un dettaglio: al primo progetto in Claude Code Projects, appena lo crei, Claude fa un turno di sua iniziativa. Può avviare un thread che esplora il repository e proporti un setup. Quel turno consuma già il piano.
Quanto consuma Claude Code Projects: il punto che decide se conviene
Non c'è un prezzo a parte. Un progetto usa gli stessi limiti del tuo abbonamento, solo che li brucia molto più in fretta, perché ogni thread è una sessione intera e ne girano diversi insieme. Sul piano Pro devi aspettarti di toccare il tetto prima, nei giorni in cui lo usi.
Le voci che pesano sono tre:
- I thread in esecuzione. Non esiste un numero fisso: Claude ne apre quanti ne servono. Se gli chiedi "massimo due alla volta" è una preferenza, non un blocco. Il limite imposto è di 200 thread nuovi al giorno su tutti i progetti.
- Il coordinatore, che spende token per leggere i report e decidere la mossa successiva.
- I thread che sorvegliano una pull request. Un thread fermo si risveglia quando la CI fallisce o arriva un commento di review, e ricomincia a consumare. Se non ti serve, chiedigli di smettere di seguire quella PR.
Il default è il più costoso possibile: un progetto nuovo usa Opus ovunque, con sforzo alto per i thread e basso per il coordinatore. La prima cosa che farei è abbassare modello o sforzo per i lavori di routine, e tenere Opus per i thread che lo meritano.
Altri due comportamenti da conoscere. Quando un thread tocca il limite delle cinque ore o quello settimanale non si ferma: aspetta e riparte da solo al reset. Il lavoro lasciato acceso si mangia quindi anche la finestra successiva.
Inoltre un follow-up mandato a un thread fermo da più di un'ora rilegge tutta la sua conversazione, perché la cache è scaduta. Per lavoro nuovo spesso costa meno un thread nuovo.
Oltre i limiti del piano si va solo se hai attivato tu i crediti a consumo. Un thread non può attivarli al posto tuo.
Nelle impostazioni del progetto c'è una scheda Usage con i token per thread e per modello: guardala dopo la prima giornata. Se stai valutando gli abbonamenti, ho messo a confronto i modelli di costo in Copilot CLI contro Claude Code.
Claude Code Projects, sessioni cloud, worktree, agent team: quale usare
Claude Code ha ormai diversi modi per lavorare in parallelo, ed è facile confonderli. La differenza di Claude Code Projects è che le sessioni le avvia e le segue Claude, partono tutte dallo stesso contesto e vivono nel cloud per tutta la durata del lavoro.
| Strumento | Dove gira | Chi coordina | Quando ha senso |
|---|---|---|---|
| Claude Code Projects | Cloud | Claude | Obiettivo che dura più di una sessione e continua a generare task |
| Sessione cloud singola | Cloud | Tu | Un task che sta in una sessione, come sistemare un test instabile |
| Agent view e worktree | La tua macchina | Tu | Lavoro che richiede database locale, VPN o strumenti solo tuoi |
| Agent team | Locale o cloud | Una sessione capofila | Un singolo compito diviso tra più agenti, che finisce con il compito |
| Routine | Cloud | Nessuno, è pianificata | Un task che si ripete a orario, senza conversazione intorno |
Se il dubbio è più a monte, cioè quale prodotto Anthropic usare per quale lavoro, ne parlo in Claude Cowork o Claude Code. Per il confronto con gli agenti autonomi della concorrenza c'è Devin contro Claude Code, Codex e Cursor.
I limiti di Claude Code Projects in beta
- Un progetto è di un solo utente. Non si condivide, né il progetto né i thread. Nessun controllo a livello di organizzazione durante la beta. Per un team oggi Claude Code Projects non è lo strumento giusto.
- Le modifiche non committate si possono perdere. La sandbox di un thread va in pausa tra un turno e l'altro. Se non riparte, il thread continua da un clone pulito. Nei task lunghi chiedi di fare commit e push del lavoro in corso.
- Con più repository le regole cambiano. Permessi, hook e variabili definiti in
.claude/settings.jsonvalgono solo se il progetto ha un repository. Con più repository non si applicano: le regole vanno nelle istruzioni di progetto e le variabili nell'ambiente cloud. - I thread non vedono il tuo setup locale. Skill, plugin e server MCP installati solo sul tuo computer non arrivano. Le skill vanno committate nel repository, i plugin aggiunti nelle impostazioni, i server MCP collegati come connettori dell'account.
- Un thread non si sposta. Appartiene al progetto che lo ha creato. Si può solo portare una sessione cloud dentro un progetto, non il contrario.
- I thread chiusi si archiviano da soli dopo una settimana senza attività.
Quando userei Claude Code Projects e quando no
I casi adatti sono quelli con un obiettivo unico su tante parti. Migrare un endpoint deprecato su API, web e mobile, con un thread per repository e l'indicazione di quale pull request unire per prima. Portare più servizi alla stessa configurazione di lint.
Oppure una migrazione più grande di una sessione, dove le decisioni prese all'inizio devono arrivare ai thread aperti tre giorni dopo.
Claude Code Projects funziona anche senza codice: una cartella di contratti o un export di ticket di assistenza su cui tornare con domande nuove, con i risultati consegnati come file in libreria.
Non lo userei per il fix singolo, che sta benissimo in una sessione. Non lo userei su progetti che vivono di servizi locali.
E sul codice dei clienti ci andrei con calma: prima di collegare un repository voglio sapere cosa può raggiungere l'ambiente cloud, quali segreti gli passo e cosa è bloccato senza la mia approvazione.
Sul perché serve questa prudenza con gli agenti ho scritto in Shai-Hulud, il worm npm che passa dagli agenti AI e nel pezzo sul threat report di Anthropic sulle API key.
La regola generale resta quella che emerge da 400.000 sessioni di Claude Code analizzate: chi delega bene ottiene molto di più, ma delegare bene vuol dire scrivere un brief chiaro e controllare il primo risultato. Claude Code Projects amplifica entrambe le cose, anche gli errori di brief.
Leggi anche
- Claude Cowork vs Claude Code: quale usare nel 2026
- Claude Code best practices: cosa insegnano 400.000 sessioni
- Pi coding agent: cos'è, come si usa e quando sceglierlo
- OpenAI Agents API: cos'è, quanto costa e quando usarla
In sintesi
Claude Code Projects sposta il coordinamento dei thread paralleli da te a Claude, con memoria condivisa e pull request separate. Il prezzo lo paghi in limiti del piano, che si consumano più in fretta, e in vincoli della beta: solo cloud, solo github.com, un solo utente.
Se vuoi capire se agenti e automazioni hanno senso nel tuo flusso di sviluppo o nella tua azienda, guarda cosa faccio con l'automazione AI e con lo sviluppo di web app, oppure scrivimi dalla pagina contatti: rispondo io, non un'agenzia.
