YOLO mode in Cursor 2026: Was Auto-review, Allowlist und Run Everything wirklich erlauben

Wurde der YOLO mode in Cursor entfernt?

Nein. Der YOLO mode von Cursor, eingeführt mit Version 0.44 im Dezember 2024, wurde im März 2025 in Auto-run umbenannt und lebt als Modus Run Everything weiter, unter Settings > Agents > Approvals & Execution. Seit Cursor 3.6 (Mai 2026) ist Auto-review der Standard, und deshalb ist die alte YOLO-Checkbox verschwunden. Die ganze Entwicklung laut Cursors Changelog:

Quellen: Cursors Changelog und die Dokumentation der Ausführungsmodi, geprüft am 18. Oktober 2026.

Wenn Sie einem Tutorial von 2025 gefolgt sind und den Schalter "YOLO" oder "Auto-run" nicht finden, liegt es genau daran. Die Modi finden Sie jetzt unter Settings > Agents > Approvals & Execution.

Was erlauben die Auto-run-Modi in Cursor?

Cursor hat heute drei Ausführungsmodi, die Nachfolger der Einstellung Auto-run. Auto-review führt Aufrufe auf der Allowlist und sandboxfähige Shell-Befehle aus, und ein Klassifikator-Modell beurteilt den Rest. Allowlist führt nur aus, was auf Ihrer Liste steht, und fragt bei allem anderen nach. Run Everything führt jeden Tool-Aufruf aus, ohne Sandbox, ohne Klassifikator und ohne Freigabe. Alle drei Modi gelten für Shell-Befehle, MCP-Tool-Aufrufe und Web-Abrufe.

Die Tabelle verschweigt drei Details, die darüber entscheiden, wie sicher jeder Modus in der Praxis ist.

Erstens umgehen Aufrufe auf der Allowlist die Sandbox. Cursors Dokumentation der Ausführungsmodi ist da eindeutig: Shell-, Fetch- und MCP-Aufrufe auf der Allowlist laufen außerhalb der Sandbox. Ein breiter Eintrag wie npx, zsh oder sogar find gibt dem Agenten volle Rechte für alles, was damit beginnt. Cursors eigene Mitarbeiter nannten genau diese drei als Beispiele, als sie erklärten, warum sie lieber die Sandbox gebaut haben als eine feinere Allowlist.

Zweitens ist der Klassifikator ein Modell, das ein anderes Modell beurteilt. In Auto-review schickt Cursor alles, was weder auf der Allowlist steht noch sich in der Sandbox ausführen lässt, an einen Klassifikator (Cursor nennt Gemini 3.5 Flash Lite, mit Haiku als Rückfallebene). Nach Cursors Angaben blockiert er etwa 4 % der Aktionen. Die Dokumentation fügt zwei Sätze hinzu, die man sich merken sollte: Auto-review sei "keine Sicherheitsgrenze", und "der Klassifikator kann Fehler machen".

Drittens gibt es Ask Every Time für manche Nutzer weiterhin. Neue Nutzer können den Modus seit 3.5 nicht mehr wählen; gleichwertig ist Allowlist mit leerer Liste. Wer ihn hatte, behält ihn, und noch im Oktober 2026 empfahlen Cursor-Mitarbeiter ihn nach einem komplett gelöschten Laufwerk.

Wie aktiviere ich den YOLO mode in Cursor heute?

Um den YOLO mode in Cursor zu aktivieren, öffnen Sie Settings > Agents > Approvals & Execution und wählen Run Everything. Das ist das YOLO-Verhalten: keine Abfragen, keine Sandbox, kein Klassifikator. Fehlt die Option, hat wahrscheinlich ein Team-Admin sie deaktiviert (Enterprise-Admins können Run Everything ausblenden und den Modus sperren), oder Ihre Cursor-Version ist älter als die aktuellen Modi.

In der Cursor-CLI schalten --yolo (Alias --force) und der Befehl /auto-run Run Everything ein; seit Februar 2026 genehmigt --yolo laut Cursor alles automatisch, und zwar "einheitlich bei Vertrauens-, MCP- und Befehlsfreigaben". --auto-review und /auto-review wählen stattdessen Auto-review.

Lesen Sie die nächsten zwei Abschnitte, bevor Sie ihn einschalten: Die Schutzfunktionen, die für Run Everything relevant klingen, decken weniger ab, als ihre Namen vermuten lassen.

Was blockiert die Sandbox von Cursor wirklich?

Unter macOS und Linux beschränkt die Sandbox von Cursor Shell-Befehle auf Schreibzugriffe im Workspace und sperrt das Netzwerk bis auf die Domains, die Ihre Einstellungen erlauben. Sie schützt Dateien wie .git/hooks und .cursor/*.json vor Schreibzugriffen. Lesezugriffe begrenzt sie standardmäßig nicht, und Befehle auf der Allowlist umgehen sie vollständig. Native Windows-Shells haben Stand Oktober 2026 keine Sandbox.

Die Sandbox wird vom Betriebssystem durchgesetzt, nicht vom Modell, und deshalb hält sie auch dann, wenn der Agent manipuliert wird. Unter macOS nutzt Cursor Seatbelt über sandbox-exec. Unter Linux setzt Cursor auf Landlock und seccomp und braucht Kernel 6.2 oder neuer mit unprivilegierten User-Namespaces; auf einem älteren Kernel fällt Cursor darauf zurück, vor jedem Befehl zu fragen. Für natives Windows erklärten Cursor-Mitarbeiter im Juli und erneut im Oktober 2026, dass Terminal-Befehle dort nicht in einer Sandbox laufen; der dokumentierte Weg ist WSL2 oder ein Dev-Container.

Was ein Befehl in der Sandbox darf und was nicht, mit Cursors Standardeinstellungen:

• Schreiben: nur im Workspace. Einige Pfade bleiben selbst dort schreibgeschützt: .cursor/*.json, .git/hooks/, .git/config, .vscode/ und .cursorignore.
• Netzwerk: zunächst gesperrt, dann über Ihre Netzwerkeinstellung geöffnet. Die Standardeinstellung gibt zusätzlich Cursors Liste von Entwickler-Domains frei, darunter github.com, *.googleapis.com und registry.npmjs.org. Private Adressen und der Cloud-Metadaten-Endpunkt bleiben gesperrt.
• Lesen: Die Standard-Lesegrenze ist das gesamte System, und laut Cursors Referenz ist ~/.ssh dabei "immer lesbar". Erst seit 3.23 lässt sich die Grenze auf den Workspace setzen.
• Temporäre Dateien: /tmp und die temporären Verzeichnisse der Plattform sind beschreibbar, sofern Sie das nicht abschalten.

Dazu kommen drei dokumentierte Wege hinaus:

1. Die Allowlist, wie oben beschrieben: Aufrufe auf der Allowlist laufen nie in der Sandbox.
2. Der erneute Versuch. Scheitert ein Befehl an einer Einschränkung der Sandbox, kann der Agent ihn außerhalb erneut ausführen. In Auto-review prüft der Klassifikator diesen zweiten Lauf; in den anderen Modi werden Sie gefragt.
3. Die Konfiguration im Repository selbst. Die .cursor/sandbox.json eines Projekts hat Vorrang vor Ihrer eigenen, und "type": "insecure_none" schaltet die Sandbox vollständig ab. Richtlinien von Team-Admins lassen sich durch lokale Dateien nicht abschwächen, aber ein Solo-Entwickler hat keinen Admin.

Aus der Sandbox gab es auch echte Ausbrüche, alle inzwischen behoben: Git-Hooks, die geschrieben wurden, um Code außerhalb der Sandbox auszuführen (CVE-2026-26268, behoben in 2.5), ein Arbeitsverzeichnis und Symlinks, die aus dem Workspace hinauszeigten (CVE-2026-50548 und CVE-2026-50549, behoben in 3.0), und ein Wrapper für ein Python-virtualenv, den eine Editor-Erweiterung ausführte (CVE-2026-73217, behoben in 3.1.2). Halten Sie Cursor aktuell. Unser Leitfaden zu Sandbox-Ausbrüchen von Coding-Agenten zeigt das Muster über alle Tools hinweg.

Ist Run Everything (der YOLO mode) in Cursor sicher?

Nicht auf einem Rechner, an dem Ihnen etwas liegt. Run Everything hat weder Sandbox noch Klassifikator, der Agent handelt also mit Ihrer Identität, Ihren Tokens und Ihren Dateien, und zwischen einem schädlichen Befehl und seiner Wirkung steht nur die Entscheidung des Modells, ihn nicht auszuführen. In Cursors Forum finden sich Berichte über ganze Laufwerke, die im Oktober 2026 in diesem Modus gelöscht wurden. Auf einem Rechner, den Sie wegwerfen können, ist der Modus vertretbar, überall sonst riskant.

Cursors eigenes Forum zeigt, wie das aussieht. Zwischen März und Oktober 2026 meldeten mindestens sechs Windows-Nutzer, durch einen Befehl des Agenten ein Laufwerk oder die meisten ihrer Dateien verloren zu haben, mehrere davon durch dasselbe Muster: ein cmd /c "rmdir /s /q ...", dessen Quoting brach, sodass vom Pfad nur das Stammverzeichnis des Laufwerks übrig blieb. Die Mitarbeiter sagten, das passe zu "einem Problem, das wir bereits verfolgen". Zwei dieser Berichte kamen in derselben Oktoberwoche 2026: Am 13. Oktober verlor ein Nutzer ein Laufwerk im Modus Auto-review, und die Mitarbeiter antworteten, Auto-review "hätte einen rekursiven Befehl wie diesen stoppen und zuerst fragen müssen"; am 17. Oktober verlor ein Nutzer ein 1-TB-Laufwerk im Modus Run Everything, in dem, so die Mitarbeiter, "alle Tool-Aufrufe automatisch laufen, ohne Freigabe, Sandbox oder Klassifikator". Im April 2026 berichtete The Register, dass ein Cursor-Agent die Produktionsdatenbank eines Startups samt Backups gelöscht hatte, indem er eine Hosting-API mit einem Token aufrief, das er in einer Datei ohne Bezug zur Aufgabe gefunden hatte. Welcher Ausführungsmodus aktiv war, sagt der Artikel nicht.

Zwei Schutzfunktionen klingen, als hätten sie geholfen. Sie haben es nicht:

• File-Deletion Protection deckt nur das eigene Lösch-Tool des Agenten ab. Mitarbeiter bestätigten im Oktober 2026, dass sie "nicht für Terminal-Befehle wie rd oder rmdir" gilt. Löschungen aus dem Terminal sind zudem "NICHT durch Cursor-Checkpoints oder den lokalen Verlauf abgedeckt", rückgängig machen lässt sich also nichts.
• External-File Protection hindert den Agenten daran, über seine Datei-Tools Dateien außerhalb des Workspace anzulegen oder zu ändern. Sie "blockiert nicht das Lesen von Dateien außerhalb des Workspace", und sie regelt nicht, was ein Terminal-Befehl tut.

Cursor hat nachgeschärft: Seit August 2026 blockiert Auto-review rekursive und erzwungene Löschungen, statt sie automatisch auszuführen, und die CLI vom 8. Oktober 2026 fragt vor Löschungen nach, "deren Ziel anders aufgelöst werden könnte als geschrieben". Der Bericht vom 13. Oktober zeigt, warum die Dokumentation das als Best Effort bezeichnet.

Unsere eigenen Daten zu ungeschützten Agenten weisen in dieselbe Richtung. In unserer vorherigen Studie, in der Agenten eine Plattform auf einer laufenden Anwendungsdatenbank bauten, führten zwei ungeschützte Konfigurationen insgesamt achtzehnmal DROP SCHEMA auf dieser Datenbank aus.

6+

Windows-Laufwerke oder -Ordner, die ein Cursor-Agent gelöscht hat, gemeldet in Cursors Forum von März bis Oktober 2026

4 %

Anteil der Aktionen, die der Klassifikator von Auto-review laut Cursor blockiert

18

DROP-SCHEMA-Läufe ungeschützter Agenten auf einer laufenden Datenbank, in unserer vorherigen Studie

Warum ist die Allowlist keine Sicherheitsgrenze?

Die Allowlist gleicht den Text eines Befehls ab, und derselbe Befehl lässt sich auf viele Arten schreiben. Cursors Dokumentation sagt es offen: Die Allowlist sei "Best Effort, keine Sicherheitsgrenze. Entschlossene Agenten oder Prompt Injection könnten sie umgehen." So funktioniert der Abgleich heute:

• Einträge sind Präfixe und unterscheiden Groß- und Kleinschreibung: git passt auf git status, aber nicht auf gitk. npm:install* trennt den Befehl von einem Muster für die Argumente. Reguläre Ausdrücke gibt es nicht.
• Eine Befehlskette wird Befehl für Befehl geprüft: cd api && npm test | tail -20 läuft nur dann automatisch, wenn cd, npm und tail jeweils auf der Liste stehen.
• Befehle auf der Allowlist laufen außerhalb der Sandbox, ein einziger breiter Eintrag hebt die Sandbox also für alles auf, was mit ihm beginnt.

Die Geschichte der Umgehungen ist lang und öffentlich. Verkettete Befehle schlüpften schon in der YOLO-Ära an beiden Listen vorbei, weshalb Cursor die Denylist in 1.3 gestrichen hat. Seitdem hat Cursor Sicherheitshinweise veröffentlicht: zu einer Umgehung der Allowlist über Backticks und $(...) (CVE-2025-54131), zu Shell-Built-ins, die liefen, ohne auf der Liste zu stehen (CVE-2026-22708), und zur Ausführung von Befehlen unter "Use AllowList" per Prompt Injection von einer Website (CVE-2026-31854). Im August 2026 zeigte ein Nutzer zwei PowerShell-Schreibweisen, die hinter einem Eintrag auf der Allowlist beliebige Befehle automatisch ausführten; die Mitarbeiter gaben sie an das Team weiter und sagten Ende September, Skriptblöcke verlangten jetzt immer eine Freigabe.

Warum funktioniert Auto-run oder meine Allowlist in Cursor nicht?

Wenn Cursor ständig nach einer Freigabe fragt oder Ihre Allowlist zu ignorieren scheint, steckt meist eine dieser Ursachen dahinter:

• Eine nicht leere terminalAllowlist in ~/.cursor/permissions.json legt den Modus auf Allowlist fest, und Auto-review steht nicht mehr zur Verfügung (Cursor-Mitarbeiter, August 2026).
• Ein verketteter Befehl läuft nur dann ohne Abfrage, wenn jeder einzelne Befehl darin auf der Liste steht.
• Unter Linux braucht die Sandbox Kernel 6.2 oder neuer mit unprivilegierten User-Namespaces. Fehlt das, fragt Cursor vor jedem Befehl nach.
• Ein Team-Admin hat den Ausführungsmodus gesperrt oder Run Everything ausgeblendet.
• Im alten Modus Run in Sandbox wurde die Allowlist überhaupt nicht angewendet, denn, so Cursor, "die Sandbox soll die Allowlist ersetzen".

Schützt .cursorignore die .env-Datei in Cursor?

Nur teilweise: Ein Terminal-Befehl, der außerhalb der Sandbox läuft, kann weiterhin cat .env ausführen. .cursorignore verbirgt Dateien vor den Datei-Tools des Agenten, vor Tab und vor @-Erwähnungen, und Cursors Standard-Ignore-Liste enthält .env* bereits. Zum Rest ist die Dokumentation deutlich: "Die Terminal- und MCP-Server-Tools, die der Agent nutzt, können den Zugriff auf Code, der unter .cursorignore fällt, nicht blockieren." In der Sandbox sind die in .cursorignore aufgeführten Dateien nicht lesbar, tragen Sie .env* also selbst in .cursorignore ein, statt sich auf die Standardliste zu verlassen. Außerhalb der Sandbox, also in Run Everything, bei Befehlen auf der Allowlist, bei genehmigten Ausbrüchen aus der Sandbox und unter nativem Windows, funktioniert cat .env.

Wenn eine Datei das Modell nie erreichen darf, halten Sie sie aus dem Workspace heraus oder unterbinden Sie schon den Lesezugriff; genau darum geht es in den nächsten zwei Abschnitten. Dieselbe Frage für Claude Code beantwortet unser Artikel dazu, was Claude Code an Anthropic sendet.

Welchen Ausführungsmodus sollten Sie in Cursor nutzen?

Auf einem Entwicklerrechner würden wir heute diese Konfiguration verwenden:

1. macOS oder Linux: Auto-review mit aktiver Sandbox. Beschränken Sie die Allowlist auf reine Lesebefehle (git status, git diff, ls) und pflegen Sie sie in der Einstellungsoberfläche statt in permissions.json, wenn Auto-review verfügbar bleiben soll.
2. Begrenzen Sie Lesezugriffe und Netzwerk in ~/.cursor/sandbox.json (die Lesegrenze braucht Cursor 3.23 oder neuer), und wählen Sie die Netzwerkeinstellung, die nur sandbox.json verwendet, falls Sie Cursors Standard-Domains nicht wollen:

{
  "readBoundary": "workspace",
  "networkPolicy": {
    "default": "deny",
    "allow": ["registry.npmjs.org", "pypi.org", "files.pythonhosted.org"]
  }
}

Braucht eine Toolchain eine Datei außerhalb des Projekts, tragen Sie sie in additionalReadPaths ein, statt das ganze System wieder zu öffnen. 3. Natives Windows: Allowlist mit leerer Liste, oder verlegen Sie das Projekt nach WSL2 oder in einen Dev-Container, wo es die Sandbox gibt. 4. Teams: zentral durchsetzen. Cursors eigener Härtungsleitfaden empfiehlt, den Ausführungsmodus der Organisation "auf Auto-review (nicht Run Everything)" zu setzen, mit aktivem Sandboxing, und Hooks über das Dashboard zu verteilen. Beachten Sie, dass in Organisationsgruppen die lockerste Sandbox-Einstellung gewinnt. 5. Run Everything nur dort, wo der Rechner entbehrlich ist:

Frischer Container oder VM, Wegwerf-KlonKeine langlebigen Tokens oder Cloud-Zugangsdaten darinAusgehender Verkehr nur zu den benötigten RegistriesDann, und nur dann, Run Everything

Cursors Cloud Agents folgen diesem Modell bereits: Jeder läuft in seiner eigenen microVM und fragt nie nach einer Freigabe; der Internetzugang ist standardmäßig an, sofern Sie ihn nicht einschränken.

Laufen Cursor-Hooks auch im Modus Run Everything?

Ja, und das macht sie zur einzigen Kontrolle, die jeden Ausführungsmodus überlebt. Ein Hook ist ein Skript, das Cursor vor einer Aktion aufruft; es kann deny antworten, und die Aktion läuft nicht. Auf die Frage, wie man eine Konfiguration mit Run Everything vor rekursiven Löschungen schützt, antworteten Cursor-Mitarbeiter am 17. Oktober 2026: "Der wichtigste Schutz dort ist der Hook."

Hier ein minimaler Hook auf Benutzerebene, der rekursive Löschungen in jeder Shell verweigert, die Cursor nutzt. In ~/.cursor/hooks.json:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      { "command": "node ./hooks/block-recursive-delete.mjs", "timeout": 5, "failClosed": true }
    ]
  }
}

Und ~/.cursor/hooks/block-recursive-delete.mjs (Hook-Pfade auf Benutzerebene werden ab ~/.cursor/ aufgelöst):

let raw = "";
for await (const chunk of process.stdin) raw += chunk;
const { command = "" } = JSON.parse(raw || "{}");

const RECURSIVE_DELETE = [
  /\brm\s+(-[a-zA-Z]*[rR][a-zA-Z]*|--recursive)\b/, // rm -rf, rm -r, rm --recursive
  /\b(rmdir|rd)\s+\/s\b/i,                         // cmd: rmdir /s, rd /s
  /\bdel\s+(\/\w\s+)*\/s\b/i,                      // cmd: del /s
  /\bRemove-Item\b[^|;&]*-Recurse\b/i,             // PowerShell
];

if (RECURSIVE_DELETE.some((re) => re.test(command))) {
  console.log(JSON.stringify({
    permission: "deny",
    user_message: `Blocked a recursive delete: ${command}`,
    agent_message: "Recursive deletes are blocked on this machine. Delete files by explicit path, or ask the user to run the command.",
  }));
} else {
  console.log(JSON.stringify({ permission: "allow" }));
}

Drei Grenzen sollten Sie kennen, bevor Sie sich darauf verlassen, alle von Cursor-Mitarbeitern bestätigt:

• Nur deny wird durchgesetzt. Im März 2026 schrieben Mitarbeiter, Hooks setzten "nur die Berechtigung deny durch. Sowohl allow als auch ask werden im Grunde ignoriert." Deshalb antwortet das Skript für alles andere mit allow: Es überlässt die Entscheidung Ihrem Ausführungsmodus. Verlassen Sie sich nicht darauf, dass ask eine Abfrage zurückbringt.
• Eine bekannte Race Condition kann ein deny verschlucken. Im Juli 2026 bestätigten Mitarbeiter, dass ein preToolUse-Hook, der deny zurückgibt, einer Race Condition zum Opfer fallen kann und der Befehl dann trotzdem läuft, und ergänzten: "Bitte verlassen Sie sich nicht allein auf einen deny-Hook als harte Sperre." Im September war das Problem noch offen.
• Hooks sehen den Ausführungsmodus nicht. Das Skript kann sich also nicht gezielt nur in Run Everything verschärfen.

Dazu kommt eine Schwäche der Methode selbst: Ein Muster ist ein Stolperdraht, keine Sicherheitsgrenze. Es fängt die Formen, die Sie aufgeschrieben haben, übersieht eine Löschung, die in einer Skriptdatei steckt oder anders geschrieben ist, und schlägt auch bei harmlosen Befehlen an: Wir haben es mit einer Reihe von Beispielbefehlen getestet, und es verweigerte rm -rf node_modules und git rm -r --cached ebenso wie die echten Komplettlöschungen. Lassen Sie die Sandbox trotzdem an.

Die Lücke, die kein Ausführungsmodus schließt

Jede Einstellung in diesem Leitfaden regelt, was Cursor ausführen darf. Keine regelt, was Cursor schreibt, und der größte Teil des Risikos in KI-generiertem Code steckt im Diff, nicht im Terminal. Auto-review lässt den Agenten anstandslos einen Endpunkt ohne Autorisierungsprüfung speichern, einen Erstattungs-Handler ohne Obergrenze oder eine per String-Verkettung gebaute Abfrage, denn nichts davon ist ein Befehl. Das sind Business-Logik-Schwachstellen, und eine Einstellung für das Terminal sieht sie nicht. Agenten beginnen außerdem jede Sitzung ohne die Regeln Ihres Teams, es sei denn, etwas legt ihnen diese Regeln genau in dem Moment vor, in dem sie schreiben.

Das ist die Schicht, die VibeDefend in Cursor ergänzt. Ein einziger Befehl installiert sie auf dem Rechner: Sie liefert dem Agenten Ihre Geschäfts- und Sicherheitsregeln, während er schreibt, prüft den Diff vor dem Commit und führt ihre Guards als Cursor-Hook vor jedem Tool-Aufruf aus, unabhängig vom Ausführungsmodus. Standardmäßig verweigern sie das Lesen von .env-Dateien, SSH-Schlüsseln und Cloud-Zugangsdaten, rm -rf auf ein Stamm- oder Home-Verzeichnis, Force-Pushes, DROP-Anweisungen und Downloads, die direkt in eine Shell geleitet werden. Der Guard ist dieselbe Art Stolperdraht wie der Hook oben, nur für Sie gepflegt, und er hat dieselben Grenzen: In unserer kontrollierten Studie vom 24. August 2026 prüfte er 1.769 Shell-Befehle und verweigerte siebzehn: ein echter Treffer, drei korrekte Anwendungen der Richtlinie und dreizehn False Positives. Beim Code selbst setzte die Konfiguration mit dieser Schicht 57 von 64 bewerteten Regeldetails exakt um (89 %), gegenüber 7 von 55 (13 %) mit einer von Hand gepflegten Regeldatei und 8 von 65 (12 %) ohne jedes Hilfsmittel.

Wenn Sie Cursor bewusst im Modus Run Everything betreiben, in einem Container, mit einem Guard im Hook, haben Sie eine vertretbare Konfiguration. Wenn Sie es so auf Ihrem Notebook betreiben, weil die Abfragen genervt haben, lesen Sie unseren Sicherheitsleitfaden für Cursor, vergleichen Sie mit dem, was --yolo in Codex abschaltet, und mit --dangerously-skip-permissions in Claude Code, und sprechen Sie dann mit uns.

Häufige Fragen

Gibt es den YOLO mode in Cursor noch?

Ja, unter anderem Namen. Der YOLO mode wurde im März 2025 in Auto-run umbenannt. Sein Verhalten "alles ausführen, ohne zu fragen" ist heute der Modus Run Everything, unter Settings > Agents > Approvals & Execution. Seit Cursor 3.6 ist Auto-review der Standardmodus.

Wie schalte ich den YOLO mode in Cursor ein?

Öffnen Sie Settings > Agents > Approvals & Execution und wählen Sie Run Everything. In der Cursor-CLI nutzen Sie --yolo (Alias --force) oder /auto-run. Fehlt die Option, hat wahrscheinlich ein Team-Admin sie deaktiviert, oder Ihre Cursor-Version ist älter als die aktuellen Modi.

Was macht Auto-review in Cursor?

Auto-review ist seit Version 3.6 (29. Mai 2026) der Standard-Ausführungsmodus von Cursor. Aufrufe auf der Allowlist laufen sofort, Shell-Befehle, die sich in der Sandbox ausführen lassen, laufen dort, und ein Klassifikator-Modell erlaubt den Rest, lenkt ihn um oder fragt bei Ihnen nach. Das gilt für Shell-, MCP- und Fetch-Aufrufe. Cursors Dokumentation sagt, Auto-review sei keine Sicherheitsgrenze.

Auto-review oder Run Everything: Was ist der Unterschied?

Auto-review führt Aufrufe auf der Allowlist aus, führt Shell-Befehle, wenn möglich, in der Sandbox aus und schickt alles andere an ein Klassifikator-Modell, das erlauben, einen anderen Weg vorschlagen oder Sie fragen kann. Run Everything führt jeden Tool-Aufruf aus, ohne Sandbox und ohne Klassifikator.

Ist Run Everything in Cursor sicher?

Nur auf einem Wegwerf-Rechner: einem frischen Container oder einer VM ohne langlebige Zugangsdaten und mit begrenztem Netzwerk. Auf einer Workstation lässt der Modus den Agenten mit Ihrer Identität handeln, und in Cursors Forum gibt es Berichte über ganze Laufwerke, die im Oktober 2026 in diesem Modus gelöscht wurden.

Wovor schützt die Sandbox von Cursor?

Unter macOS und Linux beschränkt sie Shell-Befehle auf Schreibzugriffe im Workspace, sperrt das Netzwerk bis auf die Domains, die Ihre Einstellungen erlauben, und schützt Dateien wie .cursor/*.json und .git/hooks. Lesezugriffe außerhalb des Workspace schränkt sie standardmäßig nicht ein; Cursor 3.23 hat die Lesegrenze Workspace eingeführt. Native Windows-Shells haben Stand Oktober 2026 keine Sandbox.

Cursor ignoriert meine Allowlist oder Auto-run geht nicht: Woran liegt das?

Die häufigsten Ursachen: Eine nicht leere terminalAllowlist in ~/.cursor/permissions.json legt den Modus auf Allowlist fest und deaktiviert Auto-review; ein verketteter Befehl läuft nur dann automatisch, wenn jeder Befehl darin auf der Allowlist steht; unter Linux fragt Cursor vor jedem Befehl nach, wenn der Kernel älter als 6.2 ist oder keine unprivilegierten User-Namespaces erlaubt; und im älteren Modus Run in Sandbox wurde die Allowlist gar nicht angewendet.

Gilt Auto-run auch für MCP-Tools?

Ja. MCP-Tool-Aufrufe folgen denselben Ausführungsmodi wie Terminal-Befehle. In Auto-review laufen MCP-Tools auf der Allowlist (Einträge im Format server:tool, Wildcards erlaubt) sofort, der Rest geht an den Klassifikator. In Run Everything laufen sie alle.

Kann Cursor trotz .cursorignore meine .env lesen?

Über das Terminal ja. .cursorignore verbirgt Dateien vor den Datei-Tools des Agenten und vor Erwähnungen, und .env* steht auf Cursors Standard-Ignore-Liste, aber Cursors Dokumentation hält fest, dass Terminal- und MCP-Tools den Zugriff auf ignorierte Dateien nicht blockieren können. Ein Befehl in der Sandbox kann die in .cursorignore aufgeführten Dateien nicht lesen; ein Befehl auf der Allowlist, Run Everything oder eine native Windows-Shell kann es.