Guida alla collaborazione multiplayer di Cursor Projects (beta 2026)

Dal 10 novembre 2026, Cursor ha trasformato Projects da orchestratore per singoli sviluppatori a workspace condiviso: il coordinator agent può parlare con quello di un collega, segnalare modifiche al codice sovrapposte e passare pull request ancora aperte. Per usarlo senza introdurre caos servono Cursor 3.26.13 o successivo, un account Teams e regole nette sui file di contesto condivisi: un'ipotesi non approvata di un agente non deve riscrivere il piano del repository per tutti gli altri ingegneri.

Da un solo coordinator al multiplayer: cosa cambia dal 10 novembre

Cursor Multiplayer Projects estende la beta di Projects per utente singolo, lanciata il 10 settembre 2026, a un ambiente multiutente. Ogni membro del team gestisce una chat privata 1:1 con il proprio coordinator, mentre tutti condividono una Task Board e un Project Agent Store, /cursor/stores/self. Secondo la documentazione ufficiale di Cursor Projects, l'aggiornamento del 10 novembre separa le corsie operative personali dallo stato comune del team in otto aspetti fondamentali:

Requisiti, inviti e configurazione in due fasi

In base alla documentazione di Cursor Projects, per condividere un Project multiplayer servono un account Cursor Teams o Enterprise, client 3.26.13 o successivo e accesso individuale al repository per ogni invitato. La condivisione multiplayer non è disponibile con i piani Free, Plus e Legacy Hobby; inoltre non è possibile invitare colleghi se è attiva Privacy Mode (Legacy), se il Project gira su macchine self-hosted oppure se il Project è archiviato.

Fase 1: creare il Project di base in 4 passaggi

Prima di invitare collaboratori, il proprietario inizializza lo spazio di lavoro nella Agents Window di Cursor:

1. Apri Projects dalla navigazione sinistra: apri la Agents Window, individua la sezione Projects nella barra laterale e seleziona New Project.
2. Dai un nome al Project: scegli un'icona e inserisci un nome circoscritto a un risultato specifico; lasciando il campo vuoto, il nome predefinito sarà New Project. Invece di creare un unico Project monolitico per repository, suddividilo per deliverable: uno per una migrazione dello schema, uno per una funzionalità distribuita su più PR e uno per la manutenzione ricorrente della CI.
3. Scegli workspace e modello del coordinator: nella sezione Workspace, seleziona il repository GitHub di destinazione; se GitHub non è collegato, fai clic su Connect GitHub. In Model, scegli il modello che agirà da coordinator.
4. Fai clic su Create Project: Cursor prepara un computer cloud per il Project e apre una conversazione 1:1 con il coordinator agent.

Se hai già iniziato a definire il lavoro in una chat Cloud Agent di primo livello idonea, trascina quella chat dalla sidebar sulla riga del Project, oppure apri il suo menu laterale e seleziona Add to Project: il coordinator acquisirà così la trascrizione precedente. Se si usa questa opzione con una chat locale, Cursor la converte in Remote Control prima di aggiungerla.

Fase 2: invitare i colleghi in 3 passaggi

Quando il Project è attivo e collegato a un repository, il proprietario o qualunque membro esistente può invitare colleghi seguendo i tre passaggi documentati:

1. Apri il menu degli inviti: seleziona Invite nella parte superiore del Project; dopo il primo invito, questo controllo diventa una fila di volti.
2. Invita colleghi oppure copia il link: cerca nome o email dei colleghi in Invite teammates to this project e invia l'invito, oppure scegli Copy link per condividere l'URL del Project in Slack o Linear.
3. Il collega accetta e riceve una chat dedicata: l'invitato fa clic su Accept Invite nella scheda di invito del Project e ottiene la propria chat del Project, il proprio coordinator agent e accesso in lettura e scrittura al contesto condiviso.

Controlli su membri e link

I confini di accesso vengono applicati sia a livello di team Cursor sia a livello di repository Git:

• Stesso team e accesso al repository: gli utenti con account personali e gli sviluppatori di Cursor team esterni non possono partecipare. I colleghi invitati devono inoltre avere accesso autonomo al repository del Project.
• Revocare link diffusi per errore: solo i membri esistenti del Project possono copiare il link di invito. Se un link è stato condiviso troppo ampiamente, il proprietario può aprire il menu degli inviti e selezionare Reset Share Link per invalidare tutte le copie precedenti.
• Uscita e rimozione dei membri: ogni partecipante può selezionare Leave Project dal menu laterale e rientrare in seguito tramite un invito o link valido; il proprietario può invece rimuovere un partecipante scegliendo Remove nel menu degli inviti.

Contesto condiviso (/cursor/stores/self) e store personale (/cursor/stores/user)

Come indicato nella documentazione su Context e Personal Store di Cursor Projects, Cursor Multiplayer Projects separa la configurazione privata dello sviluppatore dalla conoscenza condivisa dal team montando due percorsi distinti nel filesystem di ogni agente: /cursor/stores/self per il contesto comune del Project e /cursor/stores/user per lo user store personale. In base alle regole ufficiali degli store, quando un collega entra in un Project condiviso il suo coordinator può proporre di copiare preferenze operative rilevanti da /cursor/stores/user alle regole del Project; vengono copiate solo le voci approvate esplicitamente dall'utente.

Come comunicano i coordinator: side chat non attendibili

Quando un coordinator ha bisogno di informazioni sul lavoro di un collega, la specifica multiplayer di Cursor Projects gli consente di contattare direttamente il coordinator del collega creando, dalla chat normale del destinatario, una side chat forkata denominata Chat with {name}'s agent. Cursor limita ciò che questa side chat può eseguire, così una richiesta in arrivo non può interrompere la conversazione attiva del destinatario né esfiltrare segreti.

Nell'annuncio multiplayer del 10 novembre 2026, il product manager Aryaman Khandelwal ha illustrato due casi principali di coordinamento tra agent:

• Sovrapposizione fra UI e funzionalità: un ingegnere aggiunge recensioni dei clienti a una pagina prodotto mentre un designer ridisegna la stessa pagina. I rispettivi coordinator rilevano subito la sovrapposizione e integrano il componente delle recensioni nel nuovo layout, evitando un refactoring successivo.
• Sequenza fra schema e lettori: uno sviluppatore modifica uno schema di database mentre un collega realizza una funzionalità che legge da quel database; i loro agent concordano in anticipo l'ordine delle operazioni per evitare conflitti di integrazione al merge.

Come documentato nella sezione How coordinators message each other delle documentazioni ufficiali di Cursor Projects, questo scambio segue quattro regole rigide:

1. Richiesta in uscita: il coordinator del collega A individua una dipendenza dal lavoro del collega B e invia direttamente un messaggio al coordinator di B.
2. Creazione della side chat forkata: il messaggio in arrivo crea una side chat derivata dalla chat normale del collega B, denominata Chat with {Teammate A}'s agent.
3. Valutazione come input non attendibile: i messaggi in arrivo dei coordinator sono etichettati come input dell'agente; al destinatario viene indicato quale agente del team li ha inviati e l'agente ricevente li tratta come materiale non attendibile da valutare, non come una richiesta diretta del proprio utente.
4. Risposta con il contesto della chat principale e notifica al turno successivo: la side chat risponde usando le conoscenze disponibili nella chat principale del destinatario e restituisce la risposta al coordinator mittente. La chat principale del collega B non viene interrotta subito: riceverà invece una nota sullo scambio nel turno successivo.

La documentazione di Cursor Projects definisce il perimetro esatto dei permessi per ogni side chat forkata Chat with {name}'s agent:

Dal piano alla consegna: dove la beta può rompere le decisioni condivise

Gli esempi ufficiali di Cursor descrivono turni di reperibilità interni in cui il coordinator dell'ingegnere entrante eredita incidenti attivi, board Linear e thread Slack. I report sulla beta di Projects per utente singolo evidenziano però quattro modalità di errore lungo le quattro fasi del ciclo di vita del Project, che richiedono guardrail anche per i team:

Project Notes modificabili e il problema degli errori condivisi

In un test sul campo di 3 giorni della beta Cursor Projects per singolo utente, pubblicato sul Cursor Community Forum e comprendente 5 sessioni, circa 14 ore, 20 agent, 32 attività, 49 turni degli agent e 5 pull request di cui 4 unite, lo sviluppatore Lutz Leonhardt ha esaminato la cartella di contesto sincronizzata e le trascrizioni dell'orchestratore. Delega e consegna hanno funzionato, risolvendo tutti i 18 rilievi di un review bot Codex, ma il livello della memoria del Project ha mostrato due problemi che diventano ancora più rischiosi se proiettati su uno store multiplayer condiviso:

• 111 riscritture delle note contro 1 lettura esplicita: nei 3 giorni di test, il coordinator ha riscritto il file Project Notes 111 volte con sostituzioni dell'intero file, ma lo ha letto esplicitamente solo una volta. Il Milestone 1 è scomparso dalle note prima dell'avvio dell'archiviazione nel secondo giorno e un'approvazione esplicita per l'analisi LLM dei podcast è stata compressa in "done" dopo due riscritture; il giorno successivo il coordinator ha quindi bloccato di nuovo il lavoro sulla stessa approvazione.
• Default non approvati registrati come decisioni: dopo che il coordinator aveva elencato 5 keyword e 3 domande aperte, lo sviluppatore ha chiesto informazioni su una chiave API e se si potesse iniziare il Milestone 2. Il coordinator ha considerato i default non confermati come "accepted for the start" e ha avviato un agente che ha implementato un adapter cron sempre attivo, in contraddizione con il consiglio dato in precedenza dal coordinator. In un altro scambio, il coordinator ha negato di aver ricevuto un handoff da un worker che aveva già eseguito, scrivendo poi quella cronologia falsa nella cartella di contesto come regola di workflow.

Il report di Leonhardt riguarda Projects per singolo utente, ma con il multiplayer gli agent di ogni collega leggono e scrivono in /cursor/stores/self. Una nota inquinata o un default dell'agente non verificato può quindi influenzare qualunque agente del team che legga successivamente lo store condiviso. Come ha osservato lo sviluppatore @avisinghdotdev su X dopo il rollout multiplayer:

"Onestamente non mi piace l'idea che un agente parli con l'agente di un mio collega, soprattutto se hanno regole e skill differenti. Basta un output scadente per peggiorare la qualità." — @avisinghdotdev

Guardrail consigliato per i Project multiplayer: non lasciare che i coordinator usino un unico file Markdown modificabile in /cursor/stores/self sia come blocco appunti sia come registro delle decisioni. Configura invece le regole del Project per separare lo stato in due file:

1. Un plan.md modificabile per lo stato delle attività e i puntatori ai branch attivi.
2. Un decisions.md versionato nel repository e regolato da una policy append-only per gli agent, con verifica tramite Git diff o branch protection quando occorre un'applicazione rigorosa. Deve registrare date, decided_by (human:@handle vs agent:proposed), status (proposed, accepted, superseded), applies_to (glob del percorso file) e una rationale di una riga.

Checkout obsoleti, MCP cloud e handoff con worktree locali

Il secondo gruppo di problemi della beta nasce dall'architettura di esecuzione cloud-by-default di Cursor. In base a segnalazioni utente verificate nella ricevuta Day 7 di Cursor Projects e in discussioni su r/cursor, quattro insidie operative interessano i team che adottano Projects:

1. Checkout Git obsoleti nei Project di lunga durata: un Project cloud longevo non esegue automaticamente il pull delle modifiche unite in main (Day 7 Report R1; il team Cursor ha confermato che è il comportamento previsto e ha consigliato di chiedere al coordinator di fare pull). Nel multiplayer, istruisci sempre il coordinator a eseguire git pull prima di delegare nuove attività.
2. Caricamento dei server MCP solo dal cloud: poiché il coordinator gira come Cloud Agent, legge esclusivamente i server Model Context Protocol (MCP) configurati nelle impostazioni cloud di Cursor (Day 7 Report R6). I server MCP configurati soltanto nell'editor desktop locale non vengono caricati dal coordinator del Project.
3. La trappola dell'opzione "No self-hosted workers available": per eseguire test locali da un Project cloud, abiliti Remote Control, ovvero worker locali self-hosted, in Settings > Agents ed esegui agent login, seguito da agent worker start, nella root del repository. Tuttavia, abilitare Remote Control può attivare anche Self-hosted Machines e l'opzione Require Self-hosted Machines and Personal Machines nella dashboard del team: questo blocca l'esecuzione di Cloud Agents e Projects nel cloud di Cursor. Gli amministratori del team dovrebbero disabilitare l'opzione Require per mantenere l'esecuzione ibrida cloud/locale.
4. Consumo di token cloud: eseguire da 10 a 20 subagent cloud in parallelo consuma rapidamente l'utilizzo incluso nel piano. Come ha segnalato su Reddit l'utente di r/cursor u/Shirc:

"Projects ha potenziale, ma al momento è un po' un pasticcio e divorerà token senza pietà." — u/Shirc in r/cursor

Per controllare il consumo di token nella stessa discussione su r/cursor, lo sviluppatore u/dryu12 consiglia di impostare Composer come modello del coordinator e di scrivere regole esplicite sui modelli da assegnare alle diverse attività delegate. Se il team usa anche bot esterni per la review CI o script agent personalizzati al di fuori della fatturazione nativa di Cursor, instradare quelle chiamate API tramite AIReiter consente di abbinare modelli economici come DeepSeek V4.1 Flash a reviewer come Claude Opus 5.5 su un unico saldo pay-as-you-go.

Collisioni nella review delle PR: ogni pull request deve avere un proprietario

Secondo la documentazione sulle subscription di Cursor Projects, non appena esiste almeno 1 subscription, che monitori un canale Slack, attività su una PR, esecuzioni CI su un branch oppure una pianificazione come every day at 8:00 AM, sopra l'input della chat compare il badge Listening.

Nel test individuale di Leonhardt durato 3 giorni, la gestione delle review sulle PR era già ambigua: il coordinator, il worker che aveva implementato la modifica e nuovi agent di fix potevano reagire tutti agli eventi di review. In una PR il coordinator ha chiesto due volte all'autore degli interventi che l'agente originale stava già eseguendo; in un'altra, 3 agent hanno riscritto lo stesso file di stato, lasciando registrato l'autore sbagliato.

Quando più colleghi eseguono coordinator nello stesso repository, iscrivere vari coordinator a eventi PR estesi sull'intero repository aumenta il rischio di commit di fix duplicati e turni cloud sprecati. Come ha osservato su X lo sviluppatore @LabubuNoBB:

"La parte difficile non è mai stata far parlare gli agent. È decidere chi possiede cosa quando due di loro vogliono lo stesso file." — @LabubuNoBB

Regola consigliata per la proprietà delle PR: assegna nella Task Board condivisa un proprietario umano e un solo agente designato per ogni PR, includendo la responsabilità di tutti i commenti di review su quel branch, e limita le subscription del coordinator di ciascun collega alle proprie PR anziché usare wildcard sull'intero repository.

Quando condividere un Project e quando tenere chat separate

Prima di trasferire il workflow del team in un Cursor Project condiviso, confronta la struttura delle attività con i vincoli verificati nella beta 3.26.13+: