Claude Code Projects: guida pratica al coordinatore cloud

Claude Code Projects consente di affidare a un'unica conversazione un flusso di lavoro di sviluppo; il coordinatore può quindi avviare e seguire thread cloud separati per le singole attività. Il vantaggio non è avere più finestre di chat, ma perdere meno tempo a ripetere il contesto del repository, avviare sessioni e cercare il branch o la pull request che richiede attenzione.

La nuova esperienza ha iniziato a essere distribuita il 17 settembre 2026 e l'accesso resta selettivo. Questa guida spiega come verificare il proprio account, configurare un repository usa e getta, assegnare due attività indipendenti, controllare il lavoro prodotto e capire con precisione quale contesto segue ogni thread.

Claude Code Projects è un coordinatore, non una cartella

Un progetto Claude Code è una conversazione persistente con Claude, insieme alle sessioni cloud che avvia sotto forma di thread. La conversazione funziona come il responsabile di un'officina: riceve l'incarico, mentre postazioni separate eseguono i singoli lavori. Ogni postazione dispone di workspace, finestra di contesto e branch Git propri; il responsabile raccoglie i resoconti e mantiene ordinata la coda.

È un'impostazione diversa dalla precedente esperienza Projects nella chat di Claude e in Cowork. La versione precedente raggruppa conversazioni e file di riferimento. La nuova beta di Claude Code Projects aggiunge invece un coordinatore che smista il lavoro verso i thread cloud, ne segue lo stato e trasferisce il contesto del progetto nei nuovi thread.

Ogni thread parte con i repository e i file del progetto, le istruzioni, la memoria, l'ambiente cloud selezionato, i connettori dell'account e i file CLAUDE.md, le skill e i plugin presenti nei repository. Non eredita gli strumenti disponibili soltanto sul portatile.

Se si paga già un piano Claude idoneo, il conto economico diretto è favorevole. Claude Pro costa $20 al mese, oppure $17 al mese con un pagamento annuale di $200, mentre Max parte da $100 al mese. Projects non aggiunge un costo separato per le macchine virtuali cloud. Il limite è il consumo: ogni thread è una sessione Claude Code completa, quindi il lavoro in parallelo esaurisce più rapidamente le soglie del piano.

Come confronto, gli abbonamenti individuali agli agenti di coding verificati per questa guida vanno da $10 a $200 al mese tra GitHub Copilot e Cursor. Se Claude è già l'agente di coding adottato, Projects non è un'altra licenza da aggiungere allo stack. Cambia il costo del coordinamento, non quello del giudizio ingegneristico.

Prima di tutto, verifica se il tuo account ha accesso alla beta

Non basta vedere da qualche parte in Claude una funzione chiamata Projects.

1. Accedi con un account Claude Pro o Max.
2. Apri claude.ai/code oppure la scheda Code nell'app desktop.
3. Cerca Projects nella barra laterale sinistra.
4. Se non compare, la distribuzione non ha ancora raggiunto l'account. Iscriviti alla lista d'attesa di Anthropic e, nel frattempo, usa le normali sessioni cloud.

La prima ondata privilegia gli account Pro e Max che hanno già utilizzato le sessioni cloud e non dispongono dei vecchi Projects nella chat di Claude o in Cowork. Gli account Team ed Enterprise non hanno ancora accesso a questa beta riprogettata. I Projects precedenti continuano a funzionare durante la migrazione dell'esperienza da parte di Anthropic.

Se Claude Code deve ancora essere installato, autenticato e configurato con un CLAUDE.md a livello di repository, conviene partire dalla guida generale alla configurazione di Claude Code. Projects si appoggia a quelle pratiche di repository, non le sostituisce.

Come usare Claude Code Projects con un repository usa e getta

Per il primo tentativo, scegli un piccolo repository GitHub che possa essere eliminato senza conseguenze. L'obiettivo è osservare smistamento, contesto, branch e consumi, non affidare una migrazione di produzione a un coordinatore ancora in beta.

1. Sistema l'accesso a GitHub prima di creare il progetto

Per lavorare sul codice, il repository deve trovarsi su github.com. L'account GitHub collegato deve avere accesso in scrittura e la Claude GitHub App deve essere installata per quel repository. Un token creato tramite /web-setup può consentire a una normale sessione cloud di clonare un repository, ma non è sufficiente per un thread di progetto.

In questa beta, i repository GitHub Enterprise Server, GitLab e Bitbucket non sono supportati come repository di codice del progetto. Se il repository appartiene a un'organizzazione, un owner potrebbe dover approvare l'installazione della GitHub App e l'autorizzazione SSO.

2. Crea un progetto ben delimitato

Apri Projects, seleziona New project e aggiungi:

• Nome: qualcosa che ne evidenzi subito la natura temporanea, per esempio Parser Project Test.
• Obiettivo: una sola frase, per esempio Improve parser coverage and documentation without changing behavior.
• Contesto: aggiungi soltanto il repository usa e getta.

È obbligatorio solo il nome. Un obiettivo circoscritto offre al coordinatore un confine utile, mentre un solo repository evita le differenze di configurazione che emergono nei progetti con più repository.

3. Aggiungi un'istruzione permanente

Apri Project settings > Memory > Project instructions. Fornisci a ogni thread la stessa definizione di lavoro completato e gli stessi limiti di approvazione. Per esempio:

Parti dal branch predefinito. Usa un branch per ogni thread. Esegui i test pertinenti prima di dichiarare il lavoro completato. Non effettuare merge, non modificare la CI e non aggiungere dipendenze senza prima chiedere nel thread. Se manca un accesso, indica quale elemento manca e fermati.

Le istruzioni di progetto possono contenere fino a 16,000 caratteri, ma per la prima prova è meglio restare concisi. I comandi di build specifici del repository devono rimanere nel relativo CLAUDE.md. Requisiti, decisioni e criticità che emergono nel corso del progetto appartengono invece alla memoria del progetto.

4. Controlla l'ambiente cloud

Apri Project settings > Environment. Ogni nuovo thread usa l'ambiente selezionato qui, che governa l'accesso alla rete, le variabili d'ambiente, le credenziali API e gli strumenti installati da uno script di configurazione.

L'ambiente predefinito ospitato da Anthropic può raggiungere una allowlist di servizi comuni e include strumenti preinstallati. Non acquisisce automaticamente database locale, VPN, emulatore di dispositivi, configurazione della shell o credenziali presenti soltanto sul portatile. Configura l'ambiente prima di assegnare lavori che dipendono da uno di questi elementi.

5. Invia due attività che non possano entrare in conflitto

Inserisci entrambe le attività in un unico messaggio, così sarà possibile osservare il coordinatore mentre separa lavori non correlati. Devono riguardare file diversi. Per esempio:

Inizia subito, senza chiedere conferma. Crea un thread per aggiungere unit test sugli input non validi del parser. Crea un secondo thread per correggere gli esempi obsoleti nella guida API. Non modificare il comportamento del parser in produzione e non effettuare il merge di nessuno dei due branch.

Secondo Anthropic, più attività non correlate nello stesso messaggio vengono trasformate in thread separati. Ogni thread di codice crea un branch a partire dal branch predefinito del repository, a meno che non riceva istruzioni diverse. La separazione dei file è importante: branch distinti possono comunque generare conflitti se due thread intervengono sullo stesso codice.

6. Esamina i thread, non soltanto il riepilogo del coordinatore

Apri la scheda di ogni thread e annota:

Overview raggruppa il lavoro negli stati Ready for review, Waiting on you, Working, Landing, Idle e Resolved. Le altre schede raccolgono file di progetto, pull request e routine. Il coordinatore riceve i resoconti dei thread, ma non ne osserva ogni passaggio: per verificare il lavoro bisogna quindi consultare la trascrizione del thread.

7. Verifica se il lavoro successivo ritrova il contesto salvato

Quando entrambi i thread sono terminati, chiedi al coordinatore di ricordare una regola innocua, per esempio Documentation changes must preserve every runnable example. Avvia quindi un nuovo piccolo thread di documentazione e chiedigli di ripetere la regola sui branch e quella sulla documentazione prima di iniziare le modifiche.

In questo modo si controllano due percorsi distinti del contesto. Le istruzioni di progetto dovrebbero raggiungere ogni nuovo thread come mandato fisso. La memoria del progetto dovrebbe trasferire la decisione salvata tramite MEMORY.md. Il CLAUDE.md del repository costituisce un terzo livello separato, dedicato alle regole proprie del codice.

Quale contesto segue un thread e quale resta indietro

L'errore più facile è immaginare che un thread cloud sia una copia remota del portatile. Non lo è: si tratta di una nuova sessione cloud costruita combinando contesto di progetto, repository, account e ambiente.

Nei progetti con più repository c'è un'insidia da conoscere. Tutti i file CLAUDE.md, le skill e i plugin dei repository vengono caricati, ma non le regole di autorizzazione, gli hook e le impostazioni env dei repository. Le regole trasversali vanno inserite nelle istruzioni di progetto; le variabili d'ambiente, invece, nell'ambiente cloud.

I thread paralleli non sono infiniti

Anthropic non indica un numero fisso di thread eseguibili contemporaneamente. Si può chiedere al coordinatore di eseguirne due alla volta, ma è una preferenza, non un limite applicato dal sistema. Il tetto rigido distinto è di 200 nuovi thread al giorno complessivi tra tutti i progetti.

I thread in esecuzione consumano il piano. Anche il coordinatore lo utilizza mentre legge i resoconti e decide che cosa fare. Un thread che sorveglia una pull request si riattiva e consuma nuovamente il piano quando la CI fallisce o arriva un commento di revisione. Un progetto inattivo, senza thread in esecuzione, pull request sorvegliate o nuovi messaggi, non consuma nulla.

Per impostazione predefinita, i nuovi progetti usano Opus con effort elevato per i thread ed effort ridotto per il coordinatore. Prima di avviare un lotto consistente, apri Project settings > General e scegli il modello e il livello di effort meno costosi che siano comunque adatti a ciascun incarico. Poi richiedi un numero contenuto di thread simultanei. Il dato utile non è quanti thread Projects riesca ad avviare, ma quanti risultati sia possibile esaminare prima che la coda diventi solo rumore.

I sette casi d'uso che traggono più vantaggio da Projects

1. Un responsabile di piattaforma coordina una migrazione su più repository

Collega i repository server, web e mobile, quindi assegna al progetto un unico obiettivo: dismettere un endpoint deprecato. Thread separati possono aggiornare ogni chiamante su branch distinti, mentre il coordinatore tiene traccia dell'ordine e degli impedimenti. Il vantaggio è una sola coda di revisione, al posto di tre sessioni agente da sincronizzare manualmente. È il caso d'uso più efficace perché l'obiettivo dura più di una sessione e il lavoro può essere suddiviso nettamente per repository.

2. Un maintainer gestisce la coda dei bug di un servizio

Man mano che arrivano, il maintainer può incollare nuove segnalazioni di bug e stack trace nello stesso progetto. Il coordinatore può inviare una regressione al thread che sta già indagando su quell'area oppure aprirne uno nuovo usando le criticità memorizzate dal progetto. Si riducono così le ripetizioni nel briefing e resta una cronologia duratura di ogni bug in attesa di un accesso, una revisione o una decisione.

3. Un release owner esegue controlli indipendenti prima del rilascio

Assegna a thread distinti la suite di test, i link alla documentazione, l'audit delle dipendenze e la bozza delle note di rilascio. Mantieni ogni attività in sola lettura finché i risultati non sono stati esaminati. Il coordinatore può evidenziare ciò che ha superato i controlli e ciò che richiede una risposta, senza fondere le prove in un'unica trascrizione enorme. Il tempo tra checklist e decisione si accorcia, mentre la scelta finale resta al release owner.

4. Un responsabile del refactoring suddivide una modifica ampia per confini

Quando una migrazione supera una finestra di contesto, assegna moduli o pacchetti indipendenti a thread separati e inserisci l'invariante nelle istruzioni di progetto. Ogni thread convalida il proprio branch e restituisce un resoconto. Il risultato è lavoro in parallelo con una definizione permanente e condivisa di completamento. Resta il rischio di sovrapposizione architetturale: due branch che intervengono sulla stessa astrazione condivisa possono ancora produrre normali conflitti di merge.

5. Un tecnico di agenzia mantiene l'applicazione di un cliente

Crea un progetto privato per repository, istruzioni e ambiente di un solo cliente. Durante l'incarico, alimentalo con piccole correzioni, richieste di revisione e attività di documentazione. Si ottiene continuità senza mescolare il contesto dei clienti. Durante la beta, Projects appartiene a un unico utente e non può essere condiviso: è quindi una cabina di regia personale per la consegna, non un portale di collaborazione con il cliente.

6. Un responsabile del supporto tecnico analizza errori di integrazione ricorrenti

Projects non richiede un repository. Carica un'esportazione dei ticket di assistenza e la documentazione dell'integrazione, poi assegna ai thread la classificazione degli errori, la verifica degli esempi e la stesura di un piano correttivo. I file prodotti finiscono in Library. Il vantaggio è un insieme riutilizzabile di contesto del progetto, accompagnato da tracce di evidenze distinte per analisi e scrittura.

7. Un founder indipendente smaltisce un backlog eterogeneo

Invia un piccolo lotto con un'attività di test, una di documentazione e un audit del repository. Chiedi al coordinatore di eseguire soltanto due thread e di proporre in anticipo qualsiasi modifica distruttiva. Il guadagno è nell'attenzione: il founder esamina branch completati invece di sorvegliare ogni sessione. È invece una scelta poco adatta quando ogni attività deve modificare lo stesso file o richiede un servizio accessibile soltanto dal portatile del founder.

Tre prodotti complementari che vale la pena sviluppare

La beta non offre un'API Projects documentata, quindi nel breve periodo i prodotti più sensati sono quelli che affiancano il flusso di lavoro. Possono preparare il contesto, controllare lo stato di GitHub o aiutare una persona a esaminare l'output.

1. Project Readiness Auditor: l'opportunità più solida

Sviluppa un'app GitHub in sola lettura che verifichi se un repository è pronto per gli agenti di coding cloud. Dovrebbe controllare istruzioni del repository, comandi di test, protezioni dei branch, copertura della GitHub App, secret necessari e dipendenze di rete, quindi produrre una bozza delle istruzioni di progetto e una checklist per l'ambiente cloud.

La domanda per questo tipo di lavoro è già visibile: “ai powered coding agent” registra 8,100 ricerche mensili negli Stati Uniti con intento commerciale. I piani individuali ufficiali per agenti di coding verificati per questa guida costano da $10 a $200 al mese, ma una licenza a pagamento non rende automaticamente un repository sicuro per il lavoro cloud in parallelo.

La versione minima vendibile analizza un repository GitHub, pone sei domande sull'ambiente ed esporta un briefing pronto da incollare. Il punto debole è il rischio di piattaforma: Anthropic o GitHub potrebbero integrare rapidamente questi controlli, quindi il prodotto deve supportare più agenti e offrire una cronologia di audit utile, anziché limitarsi a un template per Claude.

2. Board per il ciclo di consegna dell'AI

Sviluppa una board basata su GitHub che raggruppi branch, pull request, stato della CI, commenti di revisione e approvazioni umane per obiettivo di consegna. Sarebbe destinata a un responsabile tecnico che utilizza più agenti di coding e necessita di un'unica superficie neutrale per la revisione.

“AI software development life cycle” registra 720 ricerche mensili negli Stati Uniti, ha una keyword difficulty pari a 4 e un CPC di $18.13. La versione minima legge gli eventi GitHub e li organizza in quattro stati: in lavorazione, bloccato, pronto e completato. Non deve mai accedere privatamente alla trascrizione di un progetto Claude.

Il problema è differenziarsi. GitHub e i fornitori di agenti mostrano già gran parte di queste informazioni. Il prodotto funziona solo se collega il lavoro tra fornitori diversi, conserva le prove di approvazione e spiega perché una modifica è bloccata, invece di limitarsi a disegnare una coda più gradevole.

3. Router automatico delle policy di revisione

Sviluppa un'app GitHub che applichi le policy di revisione specifiche del repository alle pull request create dagli agenti. Potrebbe richiedere un artefatto di test per le modifiche al parser, indirizzare quelle relative alla fatturazione a un revisore designato e impedire che i commenti di correzione automatica attivino automazioni privilegiate.

“Automated code review” registra 210 ricerche mensili negli Stati Uniti e presenta un CPC di $63.33: un segnale forte di intento costoso in un pubblico più ristretto. L'MVP richiede un file di policy, un controllo sulla pull request e una spiegazione compatta delle prove mancanti.

Il rischio è la sovrapposizione. I thread Claude sorvegliano già le pull request e reagiscono agli errori della CI e ai commenti di revisione. Un prodotto nuovo deve governare il rischio tra agenti e repository diversi, non imitare l'ennesimo bot revisore.

Che cosa Claude Code Projects non risolve

Projects rende al meglio quando il lavoro può essere suddiviso e il contesto necessario può risiedere in GitHub, nei file caricati, nei connettori o in un ambiente cloud. È lo strumento sbagliato per una correzione occasionale che entra in una sola sessione, per attività legate a un dispositivo locale o a una VPN, oppure per un team in cui più persone devono guidare lo stesso progetto.

Inoltre non elimina i normali rischi di consegna:

• Thread separati possono generare conflitti di merge quando i branch si sovrappongono.
• Una richiesta sul livello di concorrenza è un'istruzione per il coordinatore, non un rigido controllo del budget.
• I thread paralleli possono esaurire rapidamente i limiti Pro.
• Una sandbox sospesa potrebbe ripartire da un nuovo clone e perdere così il lavoro non ancora sottoposto a commit.
• La beta è personale: non offre condivisione del progetto né controlli a livello di organizzazione.
• Un thread non può essere spostato in un altro progetto in seguito.

La conclusione è semplice: usa Projects per coordinare attività separabili, non per delegare architettura o approvazioni. Inizia con due attività, controlla entrambe le trascrizioni e aumenta la concorrenza solo quando branch e consumi sono diventati prevedibili.

Domande frequenti

Claude Code può accedere ai progetti?

Gli account Claude Pro e Max selezionati possono utilizzare la nuova beta di Projects su claude.ai/code, nella scheda Code dell'app desktop e nelle app mobili di Claude. Se Projects non compare nella barra laterale di Code, la distribuzione non ha ancora raggiunto quell'account. Il comando da terminale chiamato claude project gestisce invece uno stato di directory locale non correlato.

Come si usa Projects in Claude Code?

Crea un progetto in Claude Code, aggiungi un obiettivo e solo i repository o i file indispensabili, scrivi una breve istruzione permanente, seleziona l'ambiente cloud e invia una o più attività alla conversazione del coordinatore. Prima di effettuare qualsiasi merge, esamina ogni thread in Overview e controllane branch, trascrizione, validazione e consumi.

Claude Code può lavorare su un progetto esistente?

Sì. È possibile creare un progetto attorno a un repository github.com esistente oppure scegliere Continue as a project da una sessione cloud già avviata. I repository di codice richiedono l'accesso in scrittura tramite l'account GitHub collegato e l'installazione della Claude GitHub App.

Quali sono le differenze principali tra Claude Projects e Claude Code?

Claude Code è l'agente di coding che opera in una sessione locale o cloud. Un progetto Claude Code riprogettato è invece il livello di coordinamento: una conversazione avvia e segue più sessioni cloud di Claude Code, fornisce loro il contesto condiviso del progetto e ne raccoglie lo stato. I vecchi Projects nella chat di Claude e in Cowork mantengono il modello di workspace basato su file e conversazioni finché la migrazione non li raggiunge.

Per realizzare un flusso di lavoro con agenti pronto per i progetti e costruito attorno a repository, approvazioni e ambiente cloud, scopri i sistemi AI per la produzione.