Mit dem Design-Modus im Cursor-Browser kannst du klicken, zeichnen oder Änderungen per Spracheingabe beschreiben, damit Agenten deine UI aktualisieren.
Klicke im Browser zwei oder mehr Elemente gleichzeitig an. Cursor sieht die ausgewählten Elemente, ihren Code, das umgebende Layout und die visuellen Zusammenhänge auf der Seite.
Bitte den Agenten, ein Element an ein anderes anzugleichen, wiederholte Inhalte zu entfernen oder eine Gruppe von Komponenten gleichzeitig anzupassen.
Beschreibe Änderungen über das Overlay im Design-Modus. Das Mikrofon bleibt verfügbar, während ein Agent noch eine Aufgabe ausführt, sodass du die nächste Änderung per Sprache in die Warteschlange stellen kannst, ohne auf den Abschluss der vorherigen zu warten.
Wir haben in den TypeScript- und Python-SDKs eine Reihe neuer Funktionen ausgeliefert. Du kannst jetzt festlegen, wie Agent- und Ausführungsmetadaten gespeichert werden, dem Agent deine eigenen Funktionen als Tools zur Verfügung stellen, lokale Tool-Aufrufe per Auto-Review leiten und Subagents beliebig tief verschachteln. Dieses Release enthält außerdem eine Reihe von Fixes für Zuverlässigkeit, Performance und die Plattform, die lokale und Cloud-SDK-Agents in Produktionsskripten, CI und benutzerdefinierten Integrationen einfacher ausführbar machen.
Du kannst dem lokalen Agent jetzt deine eigenen Tools übergeben, indem du Funktionsdefinitionen über local.customTools, bei Agent.create() oder pro send() mitgibst. Das SDK stellt sie dem Agent über einen integrierten MCP-Server namens custom-user-tools zur Verfügung, sodass das Modell deinen Code über denselben Pfad und dieselbe Berechtigungsprüfung aufruft wie jedes andere MCP-Tool.
Bisher bedeutete es, eine benutzerdefinierte Fähigkeit bereitzustellen, dass du deinen eigenen stdio- oder Remote-HTTP-MCP-Server aufsetzen und in den Agent einbinden musstest. Jetzt reicht eine Funktionsdefinition aus. Benutzerdefinierte Tools sind außerdem für jeden Subagent eines übergeordneten Agent sichtbar, sodass ein Tool, das du einmal definierst, in der gesamten Ausführung verfügbar ist.
Standardmäßig führt ein lokaler SDK-Agent Tool-Aufrufe ohne Freigabe aus, da bei einer Ausführung im Headless-Modus kein Mensch eingebunden ist. Setze local.autoReview, um diese Aufrufe stattdessen über Auto-review zu leiten. Ein Klassifikator entscheidet, welche Aufrufe automatisch ausgeführt und welche zurückgehalten werden, anstatt die Review vollständig zu umgehen.
Du steuerst diesen Klassifikator mit Anweisungen in natürlicher Sprache in permissions.json. Das Feld autoRun.allow_instructions beschreibt Arten von Aufrufen, die eher erlaubt werden sollen, und autoRun.block_instructions die, die zur Review zurückgehalten werden sollen. Du kannst zum Beispiel schreibgeschützte Prüfungen von Build-Artefakten erlauben, während bei destruktiven Vorgängen wie dem Löschen immer pausiert wird.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Beide SDKs speichern Agent- und Ausführungsmetadaten, damit du einen Agent nach einem Neustart des Prozesses fortsetzen kannst. Bisher kam dafür SQLite zum Einsatz. Du kannst jetzt stattdessen einen JSONL-Store nutzen, der eine einfache Datei schreibt, die nur erweitert wird und die du lesen, diffen und in die Versionsverwaltung einchecken kannst. Sowohl SqliteLocalAgentStore als auch JsonlLocalAgentStore werden direkt exportiert.
Wenn keine der beiden Standardoptionen zu deinem Setup passt, implementiere die öffentliche LocalAgentStore-Oberfläche und übergib sie über local.store. Erstelle einen In-Memory-Store für kurzlebige CI-Ausführungen oder nutze Postgres für die Persistenz, wenn der Agent-Zustand neben deinen übrigen Anwendungsdaten gespeichert werden soll. Das Python SDK stellt Host-, JSONL- und kombinierte JSONL-Stores über die Bridge bereit.
Subagents können jetzt ihre eigenen Subagents erzeugen und so weiter. Ein Reviewer-Subagent kann an einen Subagenten zum Schreiben von Tests delegieren, der wiederum weitere Subagents erzeugen kann, wobei jede Ebene ihren eigenen Prompt und ihr eigenes Modell behält. Sie müssen nichts aktivieren; eine Subagent-Sitzung registriert den Executor, den sie zum Aufrufen von Task benötigt, sodass die Verschachtelung automatisch für jeden Agent funktioniert, der Subagents definiert.
#Verbesserungen bei Zuverlässigkeit, Performance und der Plattform
Dieses Release enthält außerdem eine Reihe von Quality-of-Life-Fixes für beide SDKs.
Ausführungs-Korrelation: Jedes send() enthält jetzt eine von der Plattform generierte requestId, die in Run und RunResult verfügbar ist und in den In-Memory-, SQLite- und JSONL-Stores gespeichert wird. So kannst du eine Skript- oder CI-Ausführung mit Backend-Logs, Analysen und Support-Threads verknüpfen, ohne ihn aus der agentId ableiten zu müssen.
Zuverlässiges wait() bei lokalen Ausführungen: Lokale Ausführungen lösen wait() nicht mehr auf, bevor das Terminal-Ergebnis geschrieben wurde. Die Hydrierung wird so lange aktualisiert, bis die Ausführung einen Endzustand erreicht, sodass die Automatisierung ein vollständiges Ergebnis erhält.
Sichere Checkpoints beim Dispose: Das Freigeben eines lokalen Agent entfernt Checkpoint-Daten nicht mehr, wenn eine Root-Referenz fehlt, aber Checkpoint-Blobs noch vorhanden sind. Das Agent-Verzeichnis wird nur dann gelöscht, wenn wirklich nichts mehr zu behalten ist.
Cloud-Streaming über HTTP/1.1: Cloud-Agent-Sitzungen streamen jetzt korrekt über HTTP/1.1-Transporte, die von einigen Proxys, älteren Node-Fetch-Stacks und bestimmten CI-Images verwendet werden. Das Verhalten von HTTP/2 bleibt unverändert.
Leichterer Import: Beim Importieren von @cursor/sdk wird der vollständige lokale Agent-Stack nicht mehr vorzeitig geladen. Wer nur Cloud-Funktionen oder nur Typen nutzt, vermeidet die Kosten der lokalen Runtime bis zum ersten lokalen Aufruf – ganz ohne API-Änderung. Der erste lokale Aufruf verursacht einen einmaligen Import, der danach im Cache bleibt.
Eigenständige TypeScript-Typen: Veröffentlichte .d.ts-Dateien verweisen nicht mehr auf unveröffentlichte Workspace-Pakete. Das behebt TS2305- und TS2307-Fehler bei skipLibCheck: false sowie stillschweigende any-Typen bei Stream-Typen wie TurnEndedUpdate.
Gebündeltes ripgrep: Lokale Shell-Ausführungen nutzen die gebündelte plattformspezifische rg-Binärdatei, ohne deinen globalen PATH zu verändern. Unter Windows überschreibt das Voranstellen von ripgrep die Variable Path nicht mehr.
Composer 2 wird an Composer 2.5 weitergeleitet: SDK-Clients, die weiterhin auf ausgemusterte composer-2-Slugs festgelegt sind, werden automatisch zu Composer 2.5 weitergeleitet. Schnelle Varianten bleiben dabei erhalten, sodass ältere Skripte weiterlaufen.
Workspace-bezogenes list_runs: Client, AsyncClient und Agent.list_runs akzeptieren ein optionales cwd, und die Bridge greift ersatzweise auf ihren Start-Workspace zurück. Das behebt irreführende „Agent nicht gefunden“-Ergebnisse, wenn die Bridge als Subprozess läuft.
Klarere Not-Found-Fehler: Wenn nach einem Agent gesucht wird, der sich nicht im aufgelösten Workspace befindet, wird jetzt ein klarer Not-Found-Fehler statt eines schwer verständlichen internen Fehlers zurückgegeben.
Release 0.1.6 und Analysen: cursor-sdk 0.1.6 dokumentiert den Buildkite-Release-Pfad und kennzeichnet die SDK-Nutzung als sdk-python- für klarere Analysen.
Führe npm install @cursor/sdk oder pip install cursor-sdk aus, um ein Upgrade durchzuführen. Skripte, die composer-2 festlegen, wechseln automatisch zu Composer 2.5, und requestId ist eine sichere Ergänzung für dein Ausführungsmetadatenschema. Vollständige Details findest du in den TypeScript- und Python-Docs.
Mit Canvases können Agenten interaktive Artefakte wie Dashboards, Berichte und interne Tools erstellen, die du mit deinem Team teilen kannst.
Diese Version führt den Design-Modus für eine schnellere Bearbeitung von Canvas, neue Möglichkeiten zum Verständnis der Kontextnutzung und weitere Verbesserungen der Benutzerfreundlichkeit ein.
Wähle UI-Elemente direkt in einem Canvas aus und kommentiere sie, um Cursor bei Änderungen gezielt anzuleiten – genau wie im Browser. Statt Änderungen textlich zu beschreiben, kannst du direkt auf die betreffende Stelle zeigen, Feedback geben und schneller iterieren.
Cursor kann die Kontextnutzung deines Agenten jetzt als interaktiven Bericht in einem Canvas anzeigen.
Der Kontext-Explorer schlüsselt auf, wohin Token im System-Prompt, in Tool-Definitionen, Regeln, Skills und mehr fließen. Da es sich um ein Canvas handelt, kannst du dem Agenten Folgefragen stellen, und er kann den Bericht anpassen, um deine konkreten Fragen zu beantworten.
Klicke auf den im Canvas eingebetteten Button „Debug with Agent“, um Cursor in einer neuen Unterhaltung darum zu bitten, Möglichkeiten zur Reduzierung der Kontextnutzung zu identifizieren.
Geteilte Canvases können jetzt im Browser im Vollbildmodus geöffnet werden, damit sie sich leichter anderen präsentieren lassen.
Es wurde die Möglichkeit hinzugefügt, dass Agenten Buttons in Canvases einbetten können, die beim Anklicken einen bestimmten Prompt ausführen.
Die Fähigkeit des Agenten, Typfehler in Canvas zu beheben, wurde verbessert.
Das Styling von Komponenten wurde verbessert, und es wurden weitere Funktionen zur Anpassung von Diagrammen hinzugefügt.
Enterprise-Kunden können jetzt mehrere Cursor-Teams zentral verwalten – mit unterschiedlichen Steuerungsmöglichkeiten für Sicherheit, Governance, Budget und Features für jedes Team. Diese Funktionen sind jetzt allgemein für alle Enterprise-Kunden verfügbar.
Eine Organisation ist der oberste Container für die Identität, Verwaltung und Mitgliedschaften deines Unternehmens. Sie bietet Admins einen zentralen Ort, um ihr gesamtes Cursor-Setup einzusehen und zu verwalten, einschließlich einer zusammengefassten Übersicht über Ausgaben und Token-Nutzung über alle Teams hinweg.
Teams sind die organisatorische Einheit für eine Abteilung, Region oder Tochtergesellschaft. Das ist die Einheit, die Admins heute als ihre Cursor-Organisation verwalten. Wir haben diese Einheit einer Organisation untergeordnet, sodass du mehrere Teams betreiben kannst, jedes mit eigenen Einstellungen für Sicherheit, Governance, Ausgaben und Features.
Ein Benutzer kann zu mehr als einem Team gehören und in jedem eine andere Rolle haben. Für bestehende Kunden bleibt dein vorhandenes Team erhalten und wird zum Standardbereich für die Anmeldung, das Routing und das Erstellen neuer Teams.
Gruppen sind eine einfache Möglichkeit, Benutzer teamübergreifend oder innerhalb von Teams zu organisieren. Sie geben Benutzerkohorten separaten Modellzugriff, Ausgabenlimits und Agent-Berechtigungen, ohne dass dafür ein komplett neues Team eingerichtet werden muss. Wenn ein Benutzer zu mehr als einem Team oder einer Gruppe gehört, gilt jeweils die großzügigste Einstellung.
Auto-Review ist ein neuer Ausführungsmodus, mit dem Cursor länger arbeiten kann – mit weniger Freigabeaufforderungen und sichererer Ausführung.
Auto-Review gilt für Shell-, MCP- und Fetch-Tool-Aufrufe. Aufrufe auf der Allowlist werden sofort ausgeführt, und Aufrufe, die in der Sandbox ausgeführt werden können, laufen in der Sandbox. Alle anderen Agent-Aktionen werden an einen Klassifikator-Subagenten weitergeleitet, der entscheidet, ob der Aufruf erlaubt wird, ein anderer Ansatz versucht wird oder deine Freigabe eingeholt wird.
Konfiguriere deinen Ausführungsmodus unter Einstellungen > Cursor-Einstellungen > Agenten > Ausführungsmodus. Du kannst den Klassifikator-Agenten auch mit benutzerdefinierten Anweisungen steuern.
Mit dem Design-Modus im Cursor-Browser kannst du klicken, zeichnen oder Änderungen per Spracheingabe beschreiben, damit Agenten deine UI aktualisieren.
Klicke im Browser zwei oder mehr Elemente gleichzeitig an. Cursor sieht die ausgewählten Elemente, ihren Code, das umgebende Layout und die visuellen Zusammenhänge auf der Seite.
Bitte den Agenten, ein Element an ein anderes anzugleichen, wiederholte Inhalte zu entfernen oder eine Gruppe von Komponenten gleichzeitig anzupassen.
Beschreibe Änderungen über das Overlay im Design-Modus. Das Mikrofon bleibt verfügbar, während ein Agent noch eine Aufgabe ausführt, sodass du die nächste Änderung per Sprache in die Warteschlange stellen kannst, ohne auf den Abschluss der vorherigen zu warten.
Wir haben in den TypeScript- und Python-SDKs eine Reihe neuer Funktionen ausgeliefert. Du kannst jetzt festlegen, wie Agent- und Ausführungsmetadaten gespeichert werden, dem Agent deine eigenen Funktionen als Tools zur Verfügung stellen, lokale Tool-Aufrufe per Auto-Review leiten und Subagents beliebig tief verschachteln. Dieses Release enthält außerdem eine Reihe von Fixes für Zuverlässigkeit, Performance und die Plattform, die lokale und Cloud-SDK-Agents in Produktionsskripten, CI und benutzerdefinierten Integrationen einfacher ausführbar machen.
Du kannst dem lokalen Agent jetzt deine eigenen Tools übergeben, indem du Funktionsdefinitionen über local.customTools, bei Agent.create() oder pro send() mitgibst. Das SDK stellt sie dem Agent über einen integrierten MCP-Server namens custom-user-tools zur Verfügung, sodass das Modell deinen Code über denselben Pfad und dieselbe Berechtigungsprüfung aufruft wie jedes andere MCP-Tool.
Bisher bedeutete es, eine benutzerdefinierte Fähigkeit bereitzustellen, dass du deinen eigenen stdio- oder Remote-HTTP-MCP-Server aufsetzen und in den Agent einbinden musstest. Jetzt reicht eine Funktionsdefinition aus. Benutzerdefinierte Tools sind außerdem für jeden Subagent eines übergeordneten Agent sichtbar, sodass ein Tool, das du einmal definierst, in der gesamten Ausführung verfügbar ist.
Standardmäßig führt ein lokaler SDK-Agent Tool-Aufrufe ohne Freigabe aus, da bei einer Ausführung im Headless-Modus kein Mensch eingebunden ist. Setze local.autoReview, um diese Aufrufe stattdessen über Auto-review zu leiten. Ein Klassifikator entscheidet, welche Aufrufe automatisch ausgeführt und welche zurückgehalten werden, anstatt die Review vollständig zu umgehen.
Du steuerst diesen Klassifikator mit Anweisungen in natürlicher Sprache in permissions.json. Das Feld autoRun.allow_instructions beschreibt Arten von Aufrufen, die eher erlaubt werden sollen, und autoRun.block_instructions die, die zur Review zurückgehalten werden sollen. Du kannst zum Beispiel schreibgeschützte Prüfungen von Build-Artefakten erlauben, während bei destruktiven Vorgängen wie dem Löschen immer pausiert wird.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Beide SDKs speichern Agent- und Ausführungsmetadaten, damit du einen Agent nach einem Neustart des Prozesses fortsetzen kannst. Bisher kam dafür SQLite zum Einsatz. Du kannst jetzt stattdessen einen JSONL-Store nutzen, der eine einfache Datei schreibt, die nur erweitert wird und die du lesen, diffen und in die Versionsverwaltung einchecken kannst. Sowohl SqliteLocalAgentStore als auch JsonlLocalAgentStore werden direkt exportiert.
Wenn keine der beiden Standardoptionen zu deinem Setup passt, implementiere die öffentliche LocalAgentStore-Oberfläche und übergib sie über local.store. Erstelle einen In-Memory-Store für kurzlebige CI-Ausführungen oder nutze Postgres für die Persistenz, wenn der Agent-Zustand neben deinen übrigen Anwendungsdaten gespeichert werden soll. Das Python SDK stellt Host-, JSONL- und kombinierte JSONL-Stores über die Bridge bereit.
Subagents können jetzt ihre eigenen Subagents erzeugen und so weiter. Ein Reviewer-Subagent kann an einen Subagenten zum Schreiben von Tests delegieren, der wiederum weitere Subagents erzeugen kann, wobei jede Ebene ihren eigenen Prompt und ihr eigenes Modell behält. Sie müssen nichts aktivieren; eine Subagent-Sitzung registriert den Executor, den sie zum Aufrufen von Task benötigt, sodass die Verschachtelung automatisch für jeden Agent funktioniert, der Subagents definiert.
#Verbesserungen bei Zuverlässigkeit, Performance und der Plattform
Dieses Release enthält außerdem eine Reihe von Quality-of-Life-Fixes für beide SDKs.
Ausführungs-Korrelation: Jedes send() enthält jetzt eine von der Plattform generierte requestId, die in Run und RunResult verfügbar ist und in den In-Memory-, SQLite- und JSONL-Stores gespeichert wird. So kannst du eine Skript- oder CI-Ausführung mit Backend-Logs, Analysen und Support-Threads verknüpfen, ohne ihn aus der agentId ableiten zu müssen.
Zuverlässiges wait() bei lokalen Ausführungen: Lokale Ausführungen lösen wait() nicht mehr auf, bevor das Terminal-Ergebnis geschrieben wurde. Die Hydrierung wird so lange aktualisiert, bis die Ausführung einen Endzustand erreicht, sodass die Automatisierung ein vollständiges Ergebnis erhält.
Sichere Checkpoints beim Dispose: Das Freigeben eines lokalen Agent entfernt Checkpoint-Daten nicht mehr, wenn eine Root-Referenz fehlt, aber Checkpoint-Blobs noch vorhanden sind. Das Agent-Verzeichnis wird nur dann gelöscht, wenn wirklich nichts mehr zu behalten ist.
Cloud-Streaming über HTTP/1.1: Cloud-Agent-Sitzungen streamen jetzt korrekt über HTTP/1.1-Transporte, die von einigen Proxys, älteren Node-Fetch-Stacks und bestimmten CI-Images verwendet werden. Das Verhalten von HTTP/2 bleibt unverändert.
Leichterer Import: Beim Importieren von @cursor/sdk wird der vollständige lokale Agent-Stack nicht mehr vorzeitig geladen. Wer nur Cloud-Funktionen oder nur Typen nutzt, vermeidet die Kosten der lokalen Runtime bis zum ersten lokalen Aufruf – ganz ohne API-Änderung. Der erste lokale Aufruf verursacht einen einmaligen Import, der danach im Cache bleibt.
Eigenständige TypeScript-Typen: Veröffentlichte .d.ts-Dateien verweisen nicht mehr auf unveröffentlichte Workspace-Pakete. Das behebt TS2305- und TS2307-Fehler bei skipLibCheck: false sowie stillschweigende any-Typen bei Stream-Typen wie TurnEndedUpdate.
Gebündeltes ripgrep: Lokale Shell-Ausführungen nutzen die gebündelte plattformspezifische rg-Binärdatei, ohne deinen globalen PATH zu verändern. Unter Windows überschreibt das Voranstellen von ripgrep die Variable Path nicht mehr.
Composer 2 wird an Composer 2.5 weitergeleitet: SDK-Clients, die weiterhin auf ausgemusterte composer-2-Slugs festgelegt sind, werden automatisch zu Composer 2.5 weitergeleitet. Schnelle Varianten bleiben dabei erhalten, sodass ältere Skripte weiterlaufen.
Workspace-bezogenes list_runs: Client, AsyncClient und Agent.list_runs akzeptieren ein optionales cwd, und die Bridge greift ersatzweise auf ihren Start-Workspace zurück. Das behebt irreführende „Agent nicht gefunden“-Ergebnisse, wenn die Bridge als Subprozess läuft.
Klarere Not-Found-Fehler: Wenn nach einem Agent gesucht wird, der sich nicht im aufgelösten Workspace befindet, wird jetzt ein klarer Not-Found-Fehler statt eines schwer verständlichen internen Fehlers zurückgegeben.
Release 0.1.6 und Analysen: cursor-sdk 0.1.6 dokumentiert den Buildkite-Release-Pfad und kennzeichnet die SDK-Nutzung als sdk-python- für klarere Analysen.
Führe npm install @cursor/sdk oder pip install cursor-sdk aus, um ein Upgrade durchzuführen. Skripte, die composer-2 festlegen, wechseln automatisch zu Composer 2.5, und requestId ist eine sichere Ergänzung für dein Ausführungsmetadatenschema. Vollständige Details findest du in den TypeScript- und Python-Docs.
Mit Canvases können Agenten interaktive Artefakte wie Dashboards, Berichte und interne Tools erstellen, die du mit deinem Team teilen kannst.
Diese Version führt den Design-Modus für eine schnellere Bearbeitung von Canvas, neue Möglichkeiten zum Verständnis der Kontextnutzung und weitere Verbesserungen der Benutzerfreundlichkeit ein.
Wähle UI-Elemente direkt in einem Canvas aus und kommentiere sie, um Cursor bei Änderungen gezielt anzuleiten – genau wie im Browser. Statt Änderungen textlich zu beschreiben, kannst du direkt auf die betreffende Stelle zeigen, Feedback geben und schneller iterieren.
Cursor kann die Kontextnutzung deines Agenten jetzt als interaktiven Bericht in einem Canvas anzeigen.
Der Kontext-Explorer schlüsselt auf, wohin Token im System-Prompt, in Tool-Definitionen, Regeln, Skills und mehr fließen. Da es sich um ein Canvas handelt, kannst du dem Agenten Folgefragen stellen, und er kann den Bericht anpassen, um deine konkreten Fragen zu beantworten.
Klicke auf den im Canvas eingebetteten Button „Debug with Agent“, um Cursor in einer neuen Unterhaltung darum zu bitten, Möglichkeiten zur Reduzierung der Kontextnutzung zu identifizieren.
Geteilte Canvases können jetzt im Browser im Vollbildmodus geöffnet werden, damit sie sich leichter anderen präsentieren lassen.
Es wurde die Möglichkeit hinzugefügt, dass Agenten Buttons in Canvases einbetten können, die beim Anklicken einen bestimmten Prompt ausführen.
Die Fähigkeit des Agenten, Typfehler in Canvas zu beheben, wurde verbessert.
Das Styling von Komponenten wurde verbessert, und es wurden weitere Funktionen zur Anpassung von Diagrammen hinzugefügt.
Enterprise-Kunden können jetzt mehrere Cursor-Teams zentral verwalten – mit unterschiedlichen Steuerungsmöglichkeiten für Sicherheit, Governance, Budget und Features für jedes Team. Diese Funktionen sind jetzt allgemein für alle Enterprise-Kunden verfügbar.
Eine Organisation ist der oberste Container für die Identität, Verwaltung und Mitgliedschaften deines Unternehmens. Sie bietet Admins einen zentralen Ort, um ihr gesamtes Cursor-Setup einzusehen und zu verwalten, einschließlich einer zusammengefassten Übersicht über Ausgaben und Token-Nutzung über alle Teams hinweg.
Teams sind die organisatorische Einheit für eine Abteilung, Region oder Tochtergesellschaft. Das ist die Einheit, die Admins heute als ihre Cursor-Organisation verwalten. Wir haben diese Einheit einer Organisation untergeordnet, sodass du mehrere Teams betreiben kannst, jedes mit eigenen Einstellungen für Sicherheit, Governance, Ausgaben und Features.
Ein Benutzer kann zu mehr als einem Team gehören und in jedem eine andere Rolle haben. Für bestehende Kunden bleibt dein vorhandenes Team erhalten und wird zum Standardbereich für die Anmeldung, das Routing und das Erstellen neuer Teams.
Gruppen sind eine einfache Möglichkeit, Benutzer teamübergreifend oder innerhalb von Teams zu organisieren. Sie geben Benutzerkohorten separaten Modellzugriff, Ausgabenlimits und Agent-Berechtigungen, ohne dass dafür ein komplett neues Team eingerichtet werden muss. Wenn ein Benutzer zu mehr als einem Team oder einer Gruppe gehört, gilt jeweils die großzügigste Einstellung.
Auto-Review ist ein neuer Ausführungsmodus, mit dem Cursor länger arbeiten kann – mit weniger Freigabeaufforderungen und sichererer Ausführung.
Auto-Review gilt für Shell-, MCP- und Fetch-Tool-Aufrufe. Aufrufe auf der Allowlist werden sofort ausgeführt, und Aufrufe, die in der Sandbox ausgeführt werden können, laufen in der Sandbox. Alle anderen Agent-Aktionen werden an einen Klassifikator-Subagenten weitergeleitet, der entscheidet, ob der Aufruf erlaubt wird, ein anderer Ansatz versucht wird oder deine Freigabe eingeholt wird.
Konfiguriere deinen Ausführungsmodus unter Einstellungen > Cursor-Einstellungen > Agenten > Ausführungsmodus. Du kannst den Klassifikator-Agenten auch mit benutzerdefinierten Anweisungen steuern.
