Cursor Projects: Multiplayer-Zusammenarbeit im Beta-Guide (2026)

Seit dem 10. November 2026 ist Cursor Projects nicht mehr nur ein Orchestrierungswerkzeug für Einzelpersonen: Der Arbeitsbereich unterstützt nun Teams. Koordinator-Agenten können miteinander kommunizieren, sich überschneidende Codeänderungen erkennen und unfertige Pull Requests übergeben. Sicher funktioniert das mit Cursor 3.26.13 oder neuer, einem Teams-Account und klaren Regeln für gemeinsame Kontextdateien. Sonst kann eine unbestätigte Annahme eines Agents den Plan für andere Engineers im Repository überschreiben.

Was sich am 10. November änderte: vom Einzelprojekt zum Team-Workspace

Cursor Multiplayer Projects entwickelt die ursprüngliche Projects-Beta für einzelne Nutzer vom 10. September 2026 zu einem Mehrnutzer-Arbeitsbereich weiter. Jedes Teammitglied steuert dabei einen eigenen isolierten 1:1-Chat mit seinem Koordinator, während alle dasselbe Task Board und denselben Project Agent Store (/cursor/stores/self) nutzen. Laut der offiziellen Cursor-Projects-Dokumentation trennt das Update vom 10. November persönliche Ausführungspfade und gemeinsamen Teamzustand in acht zentralen Punkten:

Voraussetzungen, Einladungen und Einrichtung in zwei Phasen

Laut der Cursor-Projects-Dokumentation setzt das Teilen eines Multiplayer-Projects einen Cursor-Teams- oder Enterprise-Account, Client-Version 3.26.13 oder neuer sowie eigenen Repository-Zugriff für jede eingeladene Person voraus. Auf Free-, Plus- und Legacy-Hobby-Plänen ist Multiplayer-Sharing nicht verfügbar. Auch bei aktiviertem Privacy Mode (Legacy), bei Projects auf self-hosted machines oder bei archivierten Projects lassen sich keine Teammitglieder einladen.

Phase 1: Das Basisprojekt in 4 Schritten anlegen

Bevor Mitarbeitende eingeladen werden, richtet der Project-Eigentümer den Workspace im Agents Window von Cursor ein:

1. Projects in der linken Navigation öffnen: Öffne das Agents Window, suche in der Seitenleiste den Bereich Projects und wähle New Project.
2. Project benennen: Wähle ein Icon und vergib einen klar abgegrenzten, ergebnisorientierten Namen. Ohne Eingabe verwendet Cursor New Project. Statt ein einziges großes Project pro Repository anzulegen, solltest du Projects nach Deliverable aufteilen, etwa für eine Schema-Migration, ein Feature über mehrere PRs oder wiederkehrende CI-Wartung.
3. Workspace und Koordinator-Modell auswählen: Wähle unter Workspace das Ziel-Repository auf GitHub. Falls GitHub nicht verknüpft ist, klicke auf Connect GitHub. Unter Model legst du das Modell für den Koordinator fest.
4. Create Project anklicken: Cursor stellt einen Cloud-Computer für das Project bereit und öffnet einen 1:1-Thread mit dem Koordinator-Agenten.

Wenn die Aufgabenklärung bereits in einem berechtigten übergeordneten Cloud-Agent-Chat begonnen hat, ziehst du diesen Chat aus der Seitenleiste auf die Project-Zeile oder wählst über sein Seitenleistenmenü Add to Project. Der Koordinator übernimmt dann den bisherigen Verlauf. Bei einem lokalen Chat wandelt Cursor ihn zuvor in Remote Control um.

Phase 2: Teammitglieder in 3 Schritten einladen

Sobald das Project aktiv und mit einem Repository verbunden ist, können der Eigentümer und alle bestehenden Project-Mitglieder Teammitglieder in drei dokumentierten Schritten einladen:

1. Einladungsmenü öffnen: Wähle oben im Project Invite. Nach der ersten Einladung wird daraus eine Reihe von Avataren.
2. Teammitglieder einladen oder Freigabelink kopieren: Suche unter Invite teammates to this project nach Namen oder E-Mail-Adresse und verschicke die Einladung. Alternativ wählst du Copy link, um die Project-URL über Slack oder Linear zu teilen.
3. Einladung annehmen und eigenen Chat erhalten: Die eingeladene Person klickt auf der Einladungs-Karte des Projects auf Accept Invite. Sie erhält einen eigenen Project-Chat, einen eigenen Koordinator-Agenten sowie Lese- und Schreibzugriff auf den gemeinsamen Project-Kontext.

Mitgliedschaft und Link-Zugriff steuern

Die Zugriffsgrenzen werden sowohl auf Ebene des Cursor Teams als auch des Git-Repositorys durchgesetzt:

• Gleiches Team und Repository-Zugriff: Nutzer mit persönlichen Accounts und Entwickler aus externen Cursor Teams können nicht beitreten. Eingeladene Teammitglieder benötigen außerdem eigenen Zugriff auf das Project-Repository.
• Versehentlich verbreitete Links zurücksetzen: Nur bestehende Project-Mitglieder können den Einladungslink kopieren. Wurde ein Link zu breit geteilt, kann der Project-Eigentümer im Einladungsmenü Reset Share Link wählen und damit alle bisherigen Kopien ungültig machen.
• Mitglieder verlassen oder entfernen: Jeder Teilnehmer kann im Seitenleistenmenü Leave Project wählen und später über eine gültige Einladung oder einen Link erneut beitreten. Der Project-Eigentümer entfernt Personen über Remove im Einladungsmenü.

Gemeinsamer Kontext (/cursor/stores/self) und persönlicher Store (/cursor/stores/user)

Wie in der Cursor-Projects-Dokumentation zu Context und Personal Store festgelegt, trennt Cursor Multiplayer Projects private Entwicklerkonfigurationen von teamweitem Wissen. In der Umgebung jedes Agents werden dafür zwei unterschiedliche Dateisystempfade eingebunden: /cursor/stores/self für den gemeinsamen Project-Kontext und /cursor/stores/user für den persönlichen User Store. Tritt jemand einem geteilten Project bei, kann dessen Koordinator anbieten, relevante Arbeitspräferenzen aus /cursor/stores/user in die Project-Regeln zu kopieren. Übernommen werden ausschließlich Einträge, die der Nutzer ausdrücklich freigegeben hat.

So kommunizieren Koordinator-Agenten über nicht vertrauenswürdige Side Chats

Benötigt ein Koordinator Informationen aus der Arbeit eines Teammitglieds, darf er laut der Multiplayer-Spezifikation von Cursor Projects dessen Koordinator direkt kontaktieren. Dafür erstellt Cursor aus dem normalen Chat des Empfängers einen geforkten Side Chat namens Chat with {name}'s agent. Die möglichen Aktionen dieses Side Chats sind bewusst eingeschränkt: Eine eingehende Anfrage soll weder den aktiven Thread des Empfängers unterbrechen noch Geheimnisse abfließen lassen.

In der Multiplayer-Ankündigung vom 10. November 2026 beschrieb Produktmanager Aryaman Khandelwal zwei zentrale Szenarien für agentenübergreifende Koordination:

• Überschneidungen bei UI und Features: Ein Engineer ergänzt Kundenbewertungen auf einer Produktseite, während ein Designer genau diese Seite überarbeitet. Die Koordinatoren erkennen die Überschneidung frühzeitig und integrieren die Review-Komponente in das neue Layout, statt später aufwendig umzubauen.
• Reihenfolge bei Schema und Datenlesern: Ein Entwickler ändert ein Datenbankschema, während ein Teammitglied ein Feature baut, das aus dieser Datenbank liest. Die Agents einigen sich vorab auf die Reihenfolge, um Merge-Konflikte bei der Integration zu verhindern.

Wie unter How coordinators message each other in den offiziellen Cursor-Projects-Dokumenten beschrieben, gilt für diesen Austausch ein strikter Ablauf mit vier Regeln:

1. Ausgehende Anfrage: Der Koordinator von Teammitglied A erkennt eine Abhängigkeit von der Arbeit von Teammitglied B und schreibt direkt an dessen Koordinator.
2. Erstellung eines geforkten Side Chats: Die eingehende Nachricht erzeugt einen aus dem normalen Chat von Teammitglied B geforkten Side Chat mit dem Namen Chat with {Teammate A}'s agent.
3. Bewertung als nicht vertrauenswürdige Eingabe: Eingehende Koordinator-Nachrichten sind als Agent-Input gekennzeichnet. Der Empfänger erfährt, welcher Agent eines Teammitglieds die Nachricht gesendet hat, und behandelt sie als nicht vertrauenswürdiges Material zur Prüfung, nicht als direkte Anweisung des eigenen Nutzers.
4. Antwort mit Wissen des Hauptchats und Hinweis im nächsten Turn: Der Side Chat antwortet auf Basis des Wissens aus dem Hauptchat des Empfängers und sendet die Antwort an den anfragenden Koordinator zurück. Der Hauptchat von Teammitglied B wird nicht sofort unterbrochen, sondern erhält beim nächsten Turn einen Hinweis auf den Austausch.

Die Cursor-Projects-Dokumentation definiert die exakten Berechtigungsgrenzen jedes geforkten Chat with {name}'s agent-Side-Chats:

Vom Plan zur Auslieferung: Wo gemeinsame Entscheidungen in der Beta brechen

Cursor zeigt in offiziellen Beispielen interne On-Call-Rotationen, bei denen der Koordinator eines neu eintreffenden Engineers aktive Incidents, Linear-Boards und Slack-Threads übernimmt. Berichte aus der Solo-Projects-Beta offenbaren jedoch vier operative Fehlermuster über den vierstufigen Project-Lebenszyklus hinweg. Teams sollten dafür Schutzmechanismen einplanen:

Veränderliche Project Notes und das Problem geteilter Fehler

In einem dreitägigen Solo-Praxistest der Cursor-Projects-Beta, veröffentlicht im Cursor Community Forum, untersuchte Entwickler Lutz Leonhardt den synchronisierten Kontextordner und die Orchestrator-Transkripte. Der Test umfasste 5 Sessions, rund 14 Stunden, 20 Agents, 32 Aufgaben, 49 Agent-Turns und 5 Pull Requests, von denen 4 gemergt wurden. Delegation und Auslieferung funktionierten zwar und behoben alle 18 Findings eines Codex-Review-Bots. Die Memory-Schicht des Projects zeigte aber zwei Fehlermuster, die in einem gemeinsamen Multiplayer-Store noch riskanter werden:

• 111 Notiz-Umschreibungen gegenüber 1 explizitem Lesen: Während des dreitägigen Tests ersetzte der Koordinator die Project-Notes-Datei 111 Mal vollständig, las sie aber nur einmal ausdrücklich. Milestone 1 verschwand aus den Notizen, bevor am zweiten Tag die Archivierung begann. Eine explizite Freigabe für Podcast-LLM-Analyse wurde nach zwei Umschreibungen zu "done" verdichtet, sodass der Koordinator am nächsten Tag erneut auf dieselbe Freigabe wartete.
• Unbestätigte Defaults als Entscheidungen festgehalten: Nachdem der Koordinator 5 Keywords und 3 offene Fragen aufgelistet hatte, fragte der Entwickler nach einem API-Key und ob Milestone 2 beginnen könne. Der Koordinator interpretierte die unbestätigten Defaults als "accepted for the start" und startete einen Agent, der einen dauerhaft laufenden Cron-Adapter implementierte – entgegen der früheren Empfehlung des Koordinators. In einem anderen Austausch behauptete der Koordinator, eine bereits ausgeführte Worker-Übergabe nicht erhalten zu haben, und schrieb diese falsche Historie als Workflow-Regel in den Kontextordner.

Leonhardts Bericht bezieht sich zwar auf Solo Projects. Im Multiplayer-Modus lesen und beschreiben jedoch die Agents aller Teammitglieder /cursor/stores/self. Eine verunreinigte Notiz oder ein unbestätigter Agent-Default kann damit jeden später lesenden Team-Agent beeinflussen. Entwickler @avisinghdotdev schrieb auf X nach dem Multiplayer-Rollout dazu:

"Tbh I don't like the idea of an agent speaking with my teammate's agent, especially if they have separate sets of rules and skills. One slop can degrade the quality." — @avisinghdotdev

Empfohlene Schutzmaßnahme für Multiplayer Projects: Lass Koordinatoren nicht eine einzige veränderliche Markdown-Datei in /cursor/stores/self zugleich als Scratchpad und Entscheidungsprotokoll verwenden. Konfiguriere die Project-Regeln so, dass der Zustand auf zwei Dateien verteilt wird:

1. Eine veränderliche plan.md für Aufgabenstatus und Verweise auf aktive Branches.
2. Eine im Repository versionierte decisions.md mit einer Agent-Regel, die nur Ergänzungen erlaubt. Wo strikte Durchsetzung wichtig ist, sollte Git-Diff-Review oder Branch Protection dies absichern. Erfasse date, decided_by (human:@handle gegenüber agent:proposed), status (proposed, accepted, superseded), applies_to (Dateipfad-Glob) und eine einzeilige rationale.

Veraltete Checkouts, Cloud-MCP-Konflikte und Übergaben über lokale Worktrees

Die zweite Gruppe von Beta-Problemen entsteht durch Cursors Cloud-first-Ausführungsarchitektur. Verifizierte Nutzerberichte im Day 7 Cursor Projects receipt und Threads auf r/cursor zeigen vier operative Fallen, die Teams bei der Einführung von Projects betreffen:

1. Veraltete Git-Checkouts bei lang laufenden Projects: Ein lang laufendes Cloud Project zieht gemergte Änderungen aus main nicht automatisch. Das nennt Day 7 Report R1; Cursor-Mitarbeiter bestätigten, dass dieses Verhalten erwartet wird, und rieten dazu, den Koordinator explizit zum Pull aufzufordern. Im Multiplayer-Betrieb sollte jeder Koordinator vor der Delegation neuer Aufgaben immer git pull ausführen.
2. MCP-Server werden nur aus der Cloud geladen: Da der Koordinator als Cloud Agent läuft, liest er ausschließlich Model Context Protocol (MCP)-Server, die in den Cursor-Cloud-Einstellungen konfiguriert sind (Day 7 Report R6). MCP-Server, die nur im lokalen Desktop-Editor eingerichtet wurden, lädt der Project-Koordinator nicht.
3. Die Toggle-Falle bei "No self-hosted workers available": Für lokale Tests aus einem Cloud Project aktivierst du unter Settings > Agents Remote Control für lokale self-hosted Workers und führst im Repository-Root agent login gefolgt von agent worker start aus. Das Aktivieren von Remote Control kann jedoch zugleich Self-hosted Machines einschalten und im Team-Dashboard Require Self-hosted Machines and Personal Machines aktivieren. Dadurch werden Cloud Agents und Projects in Cursors Cloud blockiert. Team-Administratoren sollten den Require-Schalter deaktivieren, um hybride Cloud-/Local-Ausführung zu erhalten.
4. Cloud-Tokenverbrauch: Der Betrieb von 10 bis 20 parallelen Cloud-Subagents verbraucht die Plan-Usage schnell. Nutzer u/Shirc schrieb auf Reddit in r/cursor:

"Projects have potential but right now they’re a bit of a mess and will absolutely chew through tokens." — u/Shirc in r/cursor

Um den Tokenverbrauch in demselben r/cursor-Thread zu begrenzen, empfiehlt Entwickler u/dryu12 Composer als Koordinator-Modell und explizite Regeln dafür, welche Modelle welche delegierten Aufgaben erhalten. Nutzt dein Team zusätzlich externe CI-Review-Bots oder eigene Agent-Skripte außerhalb der integrierten Cursor-Abrechnung, kannst du API-Aufrufe über AIReiter bündeln. So lassen sich kostengünstige Modelle wie DeepSeek V4.1 Flash und Reviewer wie Claude Opus 5.5 über ein gemeinsames Pay-as-you-go-Guthaben kombinieren.

Kollisionen beim PR-Review: Jeder Pull Request braucht einen Verantwortlichen

Laut der Dokumentation zu Cursor-Projects-Subscriptions erscheint oberhalb der Chat-Eingabe ein Listening-Badge, sobald mindestens 1 Subscription besteht. Diese kann etwa einen Slack-Kanal, PR-Aktivität, CI-Läufe auf einem Branch oder einen Zeitplan wie every day at 8:00 AM überwachen.

Schon in Leonhardts dreitägigem Solo-Test war das Handling von PR-Reviews mehrdeutig: Der Koordinator, der ursprünglich implementierende Worker und neu erstellte Fix-Agents konnten alle auf Review-Ereignisse reagieren. Bei einem PR fragte der Koordinator den Autor zweimal nach Fixes, an denen der ursprüngliche Agent bereits arbeitete. Bei einem anderen schrieben 3 Agents dieselbe Statusdatei um und hinterließen den falschen Autor.

Wenn mehrere Teammitglieder Koordinatoren im selben Repository betreiben und mehrere davon breite Repository-PR-Ereignisse abonnieren, steigt das Risiko doppelter Fix-Commits und verschwendeter Cloud-Turns. Entwickler @LabubuNoBB formulierte es auf X so:

"The hard part was never getting agents to talk. It's deciding who owns what when two of them want the same file." — @LabubuNoBB

Empfohlene Regel für PR-Verantwortung: Weise im gemeinsamen Task Board jedem PR einen menschlichen Verantwortlichen und einen fest zugeordneten Agent zu. Diese tragen auch die Verantwortung für sämtliche Review-Kommentare auf diesem Branch. Begrenze die Subscriptions des Koordinators jedes Teammitglieds auf die eigenen PRs statt auf repositoryweite Wildcards.

Entscheidungsmatrix fürs Team: gemeinsames Project oder getrennte Chats?

Bevor ein Team-Workflow in ein gemeinsames Cursor Project umzieht, sollte die Aufgabenstruktur gegen die verifizierten Einschränkungen der Beta 3.26.13+ geprüft werden: