Cursor-Automatisierungen sparen dir Zeit, indem sie wiederkehrende Aufgaben mit jederzeit verfügbaren Agenten automatisieren. Mit diesem Release kommen der Skill /automate, neue Trigger für GitHub und Slack sowie Unterstützung für Computer-Use hinzu.
Reagiere auf eine beliebige Slack-Nachricht mit einem bestimmten Emoji, um eine Automatisierung zu starten. Bei Cursor nutzen wir dies, um bestimmte Automatisierungen direkt aus Slack auszulösen.
Cloud-Agents, die durch Automatisierungen gestartet werden, können jetzt ihre eigenen Computer nutzen, um Demos oder Artefakte ihrer Arbeit zu erstellen.
Das Computer-Use-Tool ist standardmäßig für jede Automatisierung aktiviert. Gib in deinen Anweisungen einfach an, dass der Agent eine Demo seiner Ergebnisse einfügen soll.
Aktualisiere zunächst auf die neueste Version von Cursor. Mehr erfährst du in unserer Dokumentation.
Automatisierungen können jetzt in einem unvollständigen Zustand gespeichert werden, sodass du die Seite verlassen kannst, um eine MCP-Authentifizierung einzurichten, ohne deinen Fortschritt zu verlieren
Automatisierungen können jetzt standardmäßig PRs öffnen; du musst dieses Tool nicht mehr in der UI angeben
Du kannst jetzt Memory-Dateien in der UI löschen oder deine Automatisierung per Prompt anweisen, beim Ausführen veraltete Memories zu löschen
Cursor kann dir jetzt helfen, deine Entwicklungsumgebung in der Cloud in weniger als 10 Minuten einzurichten. Du kannst den Fortschritt des Agenten in einer gemeinsamen Terminal-Sitzung verfolgen, während er Setup-Aufgaben wie die Installation von Abhängigkeiten übernimmt.
Deine Umgebung wird in einem wiederverwendbaren Snapshot erfasst, sodass zukünftige Cloud-Agenten schneller starten und Änderungen durch das Ausführen deiner Software testen können. Dabei kann der Agent über längere Zeiträume iterieren, bis die Ergebnisse verifiziert sind. Davon profitiert dein gesamtes Team, wenn die Konfiguration in .cursor/environment.json committet wird.
Nutze /in-cloud, um einen Cloud-Subagent in seiner eigenen VM für die nächste Aufgabe zu starten, die du ihm gibst. Er läuft in einer eigenen VM und auf einem eigenen Branch, sodass dein lokaler Workspace sauber und reaktionsschnell bleibt.
Das ist besonders nützlich, um lang laufende oder parallele Arbeiten zu isolieren – zum Beispiel beim Beheben von CI-Problemen, beim Untersuchen eines Issues oder beim Erkunden einer Codebase, während du lokal weiterarbeitest.
Du kannst einen Cloud-Subagent auch bitten, eine PR im Auge zu behalten, indem du auf die Quick-Action-Pill klickst oder /babysit nutzt. Der Cloud-Agent arbeitet remote iterativ daran, deine PR für den Merge vorzubereiten, ohne die lokale Sitzung zu blockieren.
Der Cloud-Subagent kann im Hintergrund laufen, ohne den Parent Agent zu unterbrechen, der lokal oder in der Cloud weiterlaufen kann.
Verschiebe Agent-Sitzungen zuverlässiger zwischen deinem lokalen Computer und der Cloud. Du kannst langlaufende Aufgaben von deiner Maschine in die Cloud auslagern und so viele Cloud-Agenten parallel ausführen, wie du möchtest. Hole einen Cloud-Agenten zurück auf deinen lokalen Rechner, um Änderungen selbst zu testen.
Die durchschnittliche Review-Dauer von Bugbot liegt jetzt bei ~90 Sekunden statt bei ~5 Minuten. Außerdem findet Bugbot im Durchschnitt 10 % mehr Bugs pro Review — 0,62 statt 0,56 — und kostet pro Ausführung ~22 % weniger.
Diese Leistungssteigerungen sind durch die Fortschritte möglich, die wir beim Training von Composer 2.5 erzielt haben und das Bugbot jetzt antreibt. Bugbot berücksichtigt Blocklisten für Modelle, und Geschwindigkeit und Leistung können je nach deiner Konfiguration variieren.
Du kannst jetzt Bugbot und die Sicherheitsprüfung mit /review ausführen, bevor du Code pushst. /review fordert dich auf, auszuwählen, welche Agenten ausgeführt werden sollen, oder führe /review-bugbot und /review-security direkt aus.
/review synchronisiert sich außerdem mit Bugbot auf GitHub und GitLab. Wenn du /review ausführst und dann eine PR mit demselben Diff öffnest, erkennt Bugbot sie, überspringt das Review und hinterlässt einen Kommentar, dass dieser Diff bereits geprüft wurde.
Verfügbar in Cursor 3.7+ und auf cursor.com/agents, CLI-Support ist bald verfügbar.
Du kannst Bugbot jetzt so konfigurieren, dass nur Änderungen seit dem letzten Review geprüft werden, damit sich das Feedback auf deine neuesten Änderungen konzentriert.
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.
Cursor-Automatisierungen sparen dir Zeit, indem sie wiederkehrende Aufgaben mit jederzeit verfügbaren Agenten automatisieren. Mit diesem Release kommen der Skill /automate, neue Trigger für GitHub und Slack sowie Unterstützung für Computer-Use hinzu.
Reagiere auf eine beliebige Slack-Nachricht mit einem bestimmten Emoji, um eine Automatisierung zu starten. Bei Cursor nutzen wir dies, um bestimmte Automatisierungen direkt aus Slack auszulösen.
Cloud-Agents, die durch Automatisierungen gestartet werden, können jetzt ihre eigenen Computer nutzen, um Demos oder Artefakte ihrer Arbeit zu erstellen.
Das Computer-Use-Tool ist standardmäßig für jede Automatisierung aktiviert. Gib in deinen Anweisungen einfach an, dass der Agent eine Demo seiner Ergebnisse einfügen soll.
Aktualisiere zunächst auf die neueste Version von Cursor. Mehr erfährst du in unserer Dokumentation.
Automatisierungen können jetzt in einem unvollständigen Zustand gespeichert werden, sodass du die Seite verlassen kannst, um eine MCP-Authentifizierung einzurichten, ohne deinen Fortschritt zu verlieren
Automatisierungen können jetzt standardmäßig PRs öffnen; du musst dieses Tool nicht mehr in der UI angeben
Du kannst jetzt Memory-Dateien in der UI löschen oder deine Automatisierung per Prompt anweisen, beim Ausführen veraltete Memories zu löschen
Cursor kann dir jetzt helfen, deine Entwicklungsumgebung in der Cloud in weniger als 10 Minuten einzurichten. Du kannst den Fortschritt des Agenten in einer gemeinsamen Terminal-Sitzung verfolgen, während er Setup-Aufgaben wie die Installation von Abhängigkeiten übernimmt.
Deine Umgebung wird in einem wiederverwendbaren Snapshot erfasst, sodass zukünftige Cloud-Agenten schneller starten und Änderungen durch das Ausführen deiner Software testen können. Dabei kann der Agent über längere Zeiträume iterieren, bis die Ergebnisse verifiziert sind. Davon profitiert dein gesamtes Team, wenn die Konfiguration in .cursor/environment.json committet wird.
Nutze /in-cloud, um einen Cloud-Subagent in seiner eigenen VM für die nächste Aufgabe zu starten, die du ihm gibst. Er läuft in einer eigenen VM und auf einem eigenen Branch, sodass dein lokaler Workspace sauber und reaktionsschnell bleibt.
Das ist besonders nützlich, um lang laufende oder parallele Arbeiten zu isolieren – zum Beispiel beim Beheben von CI-Problemen, beim Untersuchen eines Issues oder beim Erkunden einer Codebase, während du lokal weiterarbeitest.
Du kannst einen Cloud-Subagent auch bitten, eine PR im Auge zu behalten, indem du auf die Quick-Action-Pill klickst oder /babysit nutzt. Der Cloud-Agent arbeitet remote iterativ daran, deine PR für den Merge vorzubereiten, ohne die lokale Sitzung zu blockieren.
Der Cloud-Subagent kann im Hintergrund laufen, ohne den Parent Agent zu unterbrechen, der lokal oder in der Cloud weiterlaufen kann.
Verschiebe Agent-Sitzungen zuverlässiger zwischen deinem lokalen Computer und der Cloud. Du kannst langlaufende Aufgaben von deiner Maschine in die Cloud auslagern und so viele Cloud-Agenten parallel ausführen, wie du möchtest. Hole einen Cloud-Agenten zurück auf deinen lokalen Rechner, um Änderungen selbst zu testen.
Die durchschnittliche Review-Dauer von Bugbot liegt jetzt bei ~90 Sekunden statt bei ~5 Minuten. Außerdem findet Bugbot im Durchschnitt 10 % mehr Bugs pro Review — 0,62 statt 0,56 — und kostet pro Ausführung ~22 % weniger.
Diese Leistungssteigerungen sind durch die Fortschritte möglich, die wir beim Training von Composer 2.5 erzielt haben und das Bugbot jetzt antreibt. Bugbot berücksichtigt Blocklisten für Modelle, und Geschwindigkeit und Leistung können je nach deiner Konfiguration variieren.
Du kannst jetzt Bugbot und die Sicherheitsprüfung mit /review ausführen, bevor du Code pushst. /review fordert dich auf, auszuwählen, welche Agenten ausgeführt werden sollen, oder führe /review-bugbot und /review-security direkt aus.
/review synchronisiert sich außerdem mit Bugbot auf GitHub und GitLab. Wenn du /review ausführst und dann eine PR mit demselben Diff öffnest, erkennt Bugbot sie, überspringt das Review und hinterlässt einen Kommentar, dass dieser Diff bereits geprüft wurde.
Verfügbar in Cursor 3.7+ und auf cursor.com/agents, CLI-Support ist bald verfügbar.
Du kannst Bugbot jetzt so konfigurieren, dass nur Änderungen seit dem letzten Review geprüft werden, damit sich das Feedback auf deine neuesten Änderungen konzentriert.
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.
