Funktionen
Computersteuerung
Jeder Cloud-Agent läuft in seiner eigenen isolierten VM mit vollständiger Desktop-Umgebung. Die Agents können Maus und Tastatur nutzen, um Desktop und Browser zu steuern und so wie ein menschlicher Entwickler mit der von ihnen erstellten Software zu interagieren.
Das bedeutet, dass die Agents Dev-Server starten, die App im Browser öffnen, sich durch UI-Flows klicken und überprüfen können, ob ihre Änderungen funktionieren, bevor sie einen PR pushen. Mehr dazu im Ankündigungsblogbeitrag.
Demos und Artefakte
Agents können Artefakte wie Screenshots, Videos und Protokollverweise erstellen, um ihre Arbeit zu veranschaulichen. Diese Artefakte werden an den PR angehängt, sodass du Änderungen schnell überprüfen kannst, ohne den Branch lokal auszuchecken.
Artefakte in GitHub
Du kannst aktivieren, dass Cloud Agents Artefakte direkt in GitHub-Pull-Request-Beschreibungen einbetten, indem du im Cloud-Agents-Dashboard die Einstellung Allow posting artifacts to GitHub einschaltest.
GitHubs Image-Proxy erfordert öffentliche URLs. Daher verwenden Artefakte in PR-Beschreibungen lange, nicht erratbare URLs, die ohne Authentifizierung aufgerufen werden können. Zur Einordnung: Bis Mai 2023 nutzte GitHub für alle Anhänge in Issues und PRs öffentliche URLs.
Steuerung des Remote-Desktops
Du kannst die Kontrolle über den Remote-Desktop des Agenten übernehmen, um mit der Software zu interagieren, an der der Agent arbeitet. Du kannst die Kontrolle jederzeit wieder an den Agenten zurückgeben, damit er weiterarbeiten kann.
Cloud Agents laufen in einer Remote-VM, die vollständig mit deinem Repo, Abhängigkeiten, Tooling und Setup-Skripten aufgesetzt werden kann. So kannst du Änderungen direkt in der VM des Agenten testen, ohne den Branch auf deiner lokalen Maschine auszuchecken.
MCP-Tools
Cloud Agents können MCP (Model Context Protocol)-Server verwenden, die für dein Team konfiguriert sind. Dadurch erhalten Agents während der Ausführung Zugriff auf externe Tools und Datenquellen wie Datenbanken, APIs und Drittanbieterdienste.
Füge persönliche MCP-Server über das MCP-Dropdown in cursor.com/agents hinzu und aktiviere sie. Team-Admins konfigurieren gemeinsam genutzte Server unter Dashboard -> Integrationen & MCP.
Admins können gemeinsam genutzte Team-MCP-Server mit dem Standard-Team-Marketplace verknüpfen. Durch die Verknüpfung bleiben die Server für Cloud Agents verfügbar und stehen Teammitgliedern außerdem zur Installation und Konfiguration im Agent Window, in der IDE und in der CLI zur Verfügung.
Cloud Agents unterstützen OAuth für MCP-Server, die es benötigen. OAuth gilt pro Benutzer, auch für MCP-Server, die auf Teamebene gemeinsam genutzt werden.
Benutzerdefinierte MCP-Server
Sie können benutzerdefinierte MCP-Server entweder über HTTP oder stdio als Transport hinzufügen. SSE und mcp-remote werden nicht unterstützt.
MCP-Konfigurationen werden im Ruhezustand verschlüsselt gespeichert. Sensible Felder werden unkenntlich gemacht und können nach dem Speichern von keinem Nutzer mehr eingesehen werden:
env— Umgebungsvariablen für stdio-Serverheaders— Request-Header für HTTP-ServerCLIENT_SECRET— OAuth-Client-Secret für HTTP-Server
HTTP vs stdio
- HTTP (empfohlen) — Serverkonfigurationen sind in der VM-Umgebung des Cloud Agents nie vorhanden. Der Agent hat keinen Zugriff auf Refresh-Tokens, Header oder andere Zugangsdaten. Tool-Aufrufe werden über das Backend weitergeleitet.
- Stdio — Server laufen innerhalb der VM des Cloud Agents, sodass der Agent Zugriff auf die Konfiguration und Umgebungsvariablen des Servers hat. Das ist ähnlich dazu, wie stdio-MCPs in der Cursor-IDE funktionieren.
Stdio-Server sind für die Ausführung auf die VM-Umgebung angewiesen. Wir können nicht überprüfen, ob ein stdio-Server erfolgreich ausgeführt wird, bis ein Cloud Agent gestartet wird. Wir empfehlen, nach Möglichkeit HTTP-MCPs zu nutzen und dein environment setup korrekt zu konfigurieren, wenn du stdio-Server nutzt.
Cursor Cloud MCP
Das Cursor Cloud MCP ist ein integrierter Diagnoseserver, der während Cloud-Agent-Läufen verfügbar ist. Ein Agent kann die aktuelle Ausführung untersuchen, verwandte Ausführungen in derselben Umgebung durchsuchen und Transkripte, Diff-Metadaten, Umgebungsdetails, Ausführungs-Ereignisse und Setup-Protokolle abrufen, ohne Links und Dateien manuell zusammentragen zu müssen.
Team-Admins können Cursor Cloud MCP für ihr Team über MCP-Konfiguration in den Teameinstellungen deaktivieren. Siehe Team-Dashboard für weitere Informationen zu den MCP-Adminfunktionen.
Zugriff und Permissions
Cloud-Agent-Unterhaltungen können Prompts, Code, Tool-Output und Secrets enthalten. Alle Tools führen bei jeder Anfrage Zugriffsprüfungen durch.
| Rolle | Worauf du Zugriff hast |
|---|---|
| Team-Admin | Cloud-Agent-Läufe teamweit auflisten und Details dazu abrufen (einschließlich Transkripten), für Repositories und Umgebungen, auf die sie bereits Zugriff haben |
| Nicht-Admin | Nur deine eigenen Läufe und Transkripte. Du kannst über dieses MCP keine Chats anderer Teammitglieder einsehen |
Auch wenn Läufe in einer gemeinsam genutzten Umgebung aufgelistet werden, sehen Nicht-Admins nur Agenten, die sie selbst gestartet haben oder die ihnen gehören. Servicekonten unterliegen denselben Regeln wie der Nutzer- oder Teamkontext, in dem sie ausgeführt werden.
Was du einsehen kannst
| Kategorie | Beispiele |
|---|---|
| Aktuelle Ausführung | Ausführungs-ID, URL, Repo, Branch, Modell, Besitzer, Lifecycle-Status und wo die Ausführung gestartet wurde (Cursor, Slack, GitHub, API u. a.) |
| Ereignisse | Setup-, Pull-Request-, Artefakt- und MCP-Authentifizierungsergebnisse, die im Ausführungs-Dashboard angezeigt werden. Verwende get-events für die aktuelle Ausführung oder batch-fetch-details mit include_events für andere Ausführungen. Siehe die Ereignisarten unter Tools. |
| Zugehörige Ausführungen | Andere Cloud Agents in derselben Umgebung oder im selben Repository, wenn keine gespeicherte Umgebung zugeordnet ist |
| Umgebung | Umgebungsversion, vollständige Umgebungskonfiguration, Dashboard-URL und geltende Egress-Netzwerkrichtlinie |
| Transkript | Vollständige Unterhaltung zwischen Nutzer und Agent, einschließlich Tool-Aufrufen, sofern verfügbar |
| Diff-Metadaten | Ob der Agent Code geändert hat, wie viel geändert wurde und ob er eine PR geöffnet hat |
| Setup-Protokolle | Rohprotokolle aus dem environment setup und den Image-Build-Schritten |
Tools
Je nach deinem MCP-Client können Tool-Namen ein Server-Präfix enthalten (zum Beispiel cursor-cloud-run-info). Die zugrunde liegenden Tools sind:
| Tool | Zweck |
|---|---|
run-info | Rufe die Kennung, Metadaten und URL der aktuellen Ausführung ab. Starte hier. |
environment-info | Rufe die Umgebungsversion, Konfiguration, Dashboard-URL und effektive Egress-Richtlinie der aktuellen Ausführung ab. |
get-events | Liste die Dashboard-Ereignisse der aktuellen Ausführung auf, das älteste zuerst. |
list-cloud-agents | Durchsuche die in dieser Umgebung für dich sichtbaren Cloud-Agent-Läufe. Filtere nach Quelle, Status, Datum, Code-Änderungen, PR-Erstellung und Archivierungsstatus. |
batch-fetch-details | Rufe Details für bestimmte Ausführungs-IDs (bcIds) ab. Optional kannst du Transkripte, Diff-Metadaten, Setup-Protokolle, Umgebungsinfos und Ausführungs-Ereignisse über include_events einbeziehen (schreibt events.json pro Ausführung; bis zu 50 Ausführungen pro Batch). |
get-automation | Rufe die Details einer Automatisierung über ihre ID ab, etwa Name und Besitzer. |
list-environment-builds | Liste aktuelle Builds für die aktuelle Umgebung auf und überprüfe ihren Status. |
environment-build-logs | Lade die Installations- und Setup-Protokolle für einen Build herunter. |
trigger-environment-build | Führe einen Test-Build mit der aktuellen Konfiguration oder vorgeschlagenen Installations- und Startbefehlen aus. |
propose-environment-json | Lege Installations- und Startbefehle zur Prüfung vor, bevor du die Umgebung speicherst. |
take-environment-snapshot | Erstelle einen Snapshot einer Maschine, nachdem der Agent die Einrichtung ihrer Umgebung überprüft hat. |
check-environment-snapshot | Überprüfe, ob ein Umgebungs-Snapshot bereit ist. |
request-environment-setup-actions | Fordere Benutzeraktionen an, die die Einrichtung der Umgebung blockieren, etwa das Hinzufügen eines Secrets. |
Dashboard-Ereignis-kind-Werte aus get-events und aus batch-fetch-details mit include_events sind:
kind | Bedeutung |
|---|---|
setup_started | environment setup gestartet. |
setup_completed | environment setup abgeschlossen. |
setup_failed | environment setup fehlgeschlagen. |
pr_created | Pull Request geöffnet. |
pr_creation_failed | Erstellung des Pull Requests fehlgeschlagen. |
artifact_created | Walkthrough-Artefakt hochgeladen. |
mcp_auth_error | Authentifizierung des MCP-Servers fehlgeschlagen; seine Tools wurden übersprungen und die Ausführung fortgesetzt. |
Ein typischer Diagnoseablauf ist run-info → get-events → environment-info → list-cloud-agents → batch-fetch-details (setze include_events, wenn du Dashboard-Ereignisse anderer Ausführungen benötigst).
Beheben von CI-Fehlern
Cloud Agents versuchen automatisch, CI-Fehler in PRs zu beheben, die sie erstellen. Derzeit wird nur GitHub Actions unterstützt.
Cloud Agents überspringen automatische CI-Follow-ups, wenn:
- Du einen neuen Commit in den Branch gepusht hast; Cloud Agents beheben CI-Fehler in menschlichen Commits nicht automatisch.
- Du eine Follow-up-Nachricht an den Agent gesendet hast.
- Derselbe Check bereits im Basis-Commit des PRs fehlschlägt.
- Es für den PR bereits 10 Follow-ups zu CI-Fehlern gab.
Um diese Funktion für alle deine persönlichen Cloud Agents zu deaktivieren, gehe zu Cursor Dashboard → Cloud Agents → My Settings und deaktiviere die Option „Automatically fix CI Failures“.
Um diese Funktion für einen bestimmten Cloud-Agent-PR zu deaktivieren, kannst du @cursor autofix off im PR kommentieren. Um sie wieder zu aktivieren, kommentiere @cursor autofix on.
Wenn du möchtest, dass Cloud Agents CI-Fehler in deinen eigenen PRs beheben, kannst du sie einfach darum bitten, indem du Cursor wie gewohnt in einem Kommentar taggst. Zum Beispiel @cursor please fix the CI failures oder @cursor fix the CI lint check failure.
Das automatische Beheben von CI-Fehlern ist derzeit nur für Teams verfügbar; Unterstützung für Konten ohne Teams folgt in Kürze. In der Zwischenzeit kannst du ein ähnliches Verhalten erreichen, indem du den Cloud-Agent ausdrücklich bittest, den PR zu überwachen und CI-Fehler zu beheben.
OIDC-Identitätstoken
Von Cursor verwaltete Cloud-Agent-VMs können über einen lokalen Socket kurzlebige OIDC-JWTs prägen. Verwenden Sie diese, um Cloud-Rollen zu übernehmen oder interne APIs aufzurufen, ohne langlebige Schlüssel zu speichern. Siehe OIDC-Token.