Workspace Trust und was ein Repo im Agenten auslöst

Was ist Workspace Trust, und was ändert sich, wenn Sie einem Ordner vertrauen?

Im Beitrag über Hooks ging es um die Befehle, die ein Agent von selbst ausführt, im Beitrag über MCP-Sicherheit um die Server, die einem Repository hinzugefügt werden, und im Beitrag über die Sandbox darum, was die Befehle des Agenten begrenzt. Dieser Beitrag geht der Frage nach, die alle drei verbindet: Wenn Sie ein Repository mit einem Coding-Agenten öffnen, was kann das Repository den Agenten tun lassen? Die kurze Antwort:

Workspace Trust ist für den ersten Weg da. Wenn Sie einen Ordner zum ersten Mal öffnen, fragt das Tool, ob Sie ihm vertrauen, und lädt einen Teil der Einstellungen im Repository erst, wenn Sie das tun. Laut der Dokumentation von VS Code soll das verhindern, dass Code von selbst läuft; deshalb schaltet der Restricted Mode Agenten, Terminal, Tasks, Debugging, Einstellungen des Arbeitsbereichs und Erweiterungen ab oder schränkt sie ein. Was in den fünf Tools aus bleibt, bis Sie vertrauen:

Quelle: Dokumentation und Release Notes der Tools, 20. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu. In Gemini CLI liegt die Entscheidung in ~/.gemini/trustedFolders.json.

Eines haben die Tools gemeinsam: Vertrauen bekommt der Ordner, nicht sein Inhalt. Claude Code bindet das Vertrauen an die Wurzel des Repositorys, und es gilt für das ganze Repository. In Copilot CLI kommt die Abfrage nicht wieder, wenn Sie dem Ordner auch für künftige Sitzungen vertrauen; Gemini CLI fragt ebenfalls nur einmal pro Ordner. Ein Hook, der später in ein Repository kommt, dem Sie vertrauen, kann also ohne neue Abfrage laufen. Der npm-Wurm weiter unten nutzte genau diesen Weg.

In VS Code heißt einem übergeordneten Ordner zu vertrauen, jedem Ordner darunter zu vertrauen. Die Dokumentation schlägt daraus eine Ordnung vor: Repositorys, denen Sie vertrauen, in einen Ordner, unbekannte in einen anderen, und nur dem ersten vertrauen. Starten Sie Claude Code direkt in Ihrem Home-Verzeichnis, gilt das Vertrauen nur für diese Sitzung und wird nicht auf die Festplatte geschrieben.

Zu Gemini CLI sagen zwei Quellen Verschiedenes. Die Seite zu Trusted Folders (aktualisiert am 23. April) sagt, die Funktion sei standardmäßig aus; die Release Notes zu v0.59.0 (8. September) schreiben, die Vertrauensrichtlinie sei nun “fail-closed”. Sehen Sie in Ihrer eigenen Installation nach der Einstellung security.folderTrust.enabled. Google hat Gemini CLI am 18. Juni 2026 für kostenlose Nutzer sowie für Abonnenten von Google AI Pro und Ultra eingestellt und auf Antigravity CLI verwiesen; mit einem kostenpflichtigen API-Schlüssel können Sie Gemini CLI weiter nutzen.

Mit welchen Dateien kann ein Repository Code ausführen?

Öffnet ein Coding-Agent einen Ordner, können mehrere Dateien von selbst Code ausführen. Die meisten kommen per Commit ins Repository und stehen im Diff des Pull Requests. Eine steht in keinem Diff:

Dieselbe Datei kann mehr als ein Tool lesen: Copilot CLI liest auch die .claude/settings.json im Repository, und Cursor CLI führt die Hooks von Claude Code mit den eigenen zusammen. Hooks haben wir im Beitrag über Hooks ausführlich behandelt, MCP-Dateien im MCP-Beitrag. Hier geht es darum, wie Angreifer diese Dateien nutzen; beide Beispiele stammen aus August und September.

Laut dem Bericht von Aikido übernahmen Angreifer am 4. August das GitHub-Konto des Maintainers der Bibliothek keyv und brachten einen Wurm in die Pakete, der Zugangsdaten stiehlt. Am Tag darauf waren mindestens 444 Pakete und 1.381 Versionen betroffen. Fand der Wurm unter den gestohlenen Daten ein GitHub-App-Token, committete er in die Repositorys, die er erreichen konnte, in bis zu 50 Branches pro Repository. Diese Commits fügten .claude/settings.json und .vscode/tasks.json Hooks hinzu; ihr Autor war claude, ihre Nachricht chore: update config.

Laut der Analyse von Elastic Security Labs kam für Claude Code ein SessionStart-Hook hinzu, der bei jeder neuen Sitzung läuft, und für VS Code ein folderOpen-Task, der beim Öffnen des Ordners läuft. Elastics Schluss: Damit sich ein Entwickler infiziert, genügt es, das Repository zu öffnen. Laut Aikido war nicht einmal npm install nötig.

Die Vertrauensabfrage greift hier unter Umständen gar nicht: Vertrauen bekommt ein Ordner einmal, der neue Hook dagegen kommt per Commit in ein Repository, das Sie jeden Tag öffnen. In VS Code gibt es noch eine Hürde: Automatische Tasks laufen in einem nicht vertrauenswürdigen Ordner nie, und in einem Ordner, dem Sie vertrauen, fragen sie standardmäßig einmal um Erlaubnis. Im Pull Request erkennen Sie es am Diff selbst: ein „Config-Update“, das .claude/settings.json einen Hook hinzufügt. Autor und Nachricht des Commits sahen gewöhnlich aus; sehen Sie sich den Inhalt an.

Das zweite Beispiel ist die Datei, die nicht per Commit kommt. Laut GitSpawn, der Untersuchung, die Manifold Security am 1. September veröffentlicht hat, führen Coding-Agenten im Hintergrund git-Befehle aus, um Kontext zu sammeln; manche taten das, bevor Sie etwas eingegeben hatten, sogar noch vor der Vertrauensabfrage. Befehle wie git status führen beim Aktualisieren des Index das Programm aus der Einstellung core.fsmonitor aus, und git liest diese Einstellung aus der eigenen .git/config des Repositorys. Das Ergebnis, wie Manifold es beschreibt: Das Repository nennt einen Befehl, und git führt ihn mit Ihren Rechten aus, außerhalb der Sandbox und ohne jede Freigabeabfrage.

Wie die Datei ankommt, ist entscheidend. Laut Manifold löst das Klonen des Repositorys von einer bösartigen Adresse die Lücke nicht aus, fetch und pull auch nicht; git überträgt diese Einstellung nicht. Damit der Angriff funktioniert, muss das Repository mit seinem eigenen .git-Ordner kommen: als Zip-Datei, über ein gemeinsames Laufwerk, einen synchronisierten Ordner oder einen USB-Stick. Die Regel der Untersuchung passt in einen Satz: Jede Einstellung, die ein Programm nennt, kann es ausführen. Am Tag der Veröffentlichung waren 4 der 8 Feststellungen behoben; sehen Sie in den Release Notes Ihres Tools nach. Diese Datei steht in keinem Diff und kann vor der Vertrauensabfrage laufen; prüfen können Sie sie erst, wenn der Ordner bei Ihnen ankommt.

Fragt ein Agent in CI, ob Sie dem Ordner vertrauen?

Nein; es ist niemand da, den er fragen könnte. Die Tools unterscheiden sich darin, was sie stattdessen tun: Manche nutzen die Projekteinstellungen, manche laden sie gar nicht, manche brechen ab. Wenn ein Agent Ihre Pull Requests in CI prüft, sehen Sie sich diese Tabelle an:

Quelle: Dokumentation und Release Notes der Tools, 20. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu. Cursor CLI verhält sich seit Januar 2026 so. Gemini CLI bricht einen nicht interaktiven Lauf bei aktivem Ordnervertrauen mit FatalUntrustedWorkspaceError ab.

Die Dokumentation zu Berechtigungen von Claude Code zeigt diesen Fall in einer eigenen Tabelle. Bei einem claude -p-Lauf in einem Ordner, dem nie vertraut wurde, gelten die Allow-Regeln nicht, die Hooks aus der Einstellungsdatei und der env-Block aber schon. Die MCP-Seite haben wir im MCP-Beitrag behandelt. Die Dokumentation sagt auch, was bei einem Repository zu tun ist, das Sie nicht geschrieben haben: Mit --setting-sources user liest Claude Code die Einstellungsdateien des Projekts gar nicht; mit --bare liest es aus dem Projekt keine Hooks, Skills, Subagenten und Plugins, der env-Block des Projekts gilt aber weiterhin. Um Hooks abzuschalten, übergeben Sie diesem Lauf disableAllHooks mit --settings. Laut Dokumentation reicht es nicht, das nur in Ihre eigenen Benutzereinstellungen zu schreiben, weil die Projekteinstellung Ihre überschreiben und wieder auf false setzen kann.

Achten Sie in Copilot CLI auf eine Variable: Ist COPILOT_ALLOW_ALL genau true, vertraut die CLI dem Ordner ohne Rückfrage und lädt alles aus dem Repository, auch Hooks, die Shell-Befehle ausführen. Sehen Sie diese Variable in einem Workflow, prüfen Sie, ob der Job auf dem Branch des Pull Requests läuft. Die Dokumentation von Codex warnt für CI eigens: In Jobs, die Code aus dem Repository auschecken oder ausführen, setzen Sie den API-Schlüssel nicht als Umgebungsvariable auf Job-Ebene; Build-Skripte, Tests und die Installations-Hooks von Abhängigkeiten können ihn lesen.

In Gemini CLI wurde diese Lücke zu einem Sicherheitseintrag und ist inzwischen geschlossen. Laut dem Eintrag GHSA-wpqr-6v78-jr5g auf GitHub (24. April 2026, kritisch, CVSS 10,0) vertrauten ältere Versionen dem Ordner automatisch, wenn sie in CI liefen. Der Eintrag benennt das Risiko ausdrücklich: CI-Workflows, die von Nutzern eingereichte Pull Requests prüfen. Umgebungsvariablen im .gemini/-Ordner eines solchen Repositorys konnten zur Ausführung von Code aus der Ferne führen. Behoben wurde die Lücke in Gemini CLI 0.39.1 und in der Action run-gemini-cli 0.1.22; jetzt müssen Sie dem Ordner auch in einem nicht interaktiven Lauf ausdrücklich vertrauen.

Was ist Prompt Injection, und kann ein Pull Request einen Review-Bot täuschen?

Prompt Injection heißt, Anweisungen in einen Text zu setzen, den ein Modell liest, um sein Verhalten zu ändern. OWASP unterscheidet zwei Arten: die direkte Prompt Injection über die eigene Eingabe des Nutzers und die indirekte Prompt Injection, versteckt in einer Webseite oder Datei, die das Modell von außen liest. Laut OWASP muss der Text für Menschen nicht einmal sichtbar sein; es genügt, dass das Modell ihn liest. Bei einem Coding-Agenten kann dieser Text eine Datei im Repository sein, die Beschreibung eines Pull Requests, ein Issue oder ein Kommentar.

Workspace Trust schließt diesen Weg nicht: Sobald Sie den Agenten in einem Ordner laufen lassen, lassen Sie ihn auch den Text in diesem Ordner lesen. Deshalb empfiehlt die Dokumentation von VS Code, ein Projekt, das Sie nicht geprüft haben, im Restricted Mode zu öffnen. Jede Datei, die der Agent in seinen Kontext holt, kann zu Prompt Injection führen; im Restricted Mode laufen Agenten gar nicht. Gegen Text bleiben Ihnen zwei Mittel: wo die Regeln gelesen werden und was der Agent darf.

Wie weit das in CI gehen kann, hat GitInject (7. Juni 2026) an echten GitHub-Workflows gemessen. Die Forscher testeten die Workflow-Konfigurationen von 4 KI-Anbietern und dokumentierten 11 Angriffe. Sie fallen in vier Klassen: Injektion in Konfigurationsdateien, Abfluss von Zugangsdaten, Manipulation des Urteils und Störung der Verfügbarkeit. Jeder getestete Anbieter war in seiner Standardkonfiguration für mindestens eine Klasse anfällig. Laut den Autoren entstehen die ernstesten Lücken nicht aus dem Verhalten des Modells, sondern daraus, wie die CI-Infrastruktur mit Zugangsdaten und Konfigurationsdateien umgeht.

Um einen Review-Bot zu täuschen, muss man nicht einmal Anweisungen schreiben. PRWeaver (3. August 2026) baute in 10 echten Repositorys 208 Angriffe, jeden durch Ausführen bestätigt, und ließ jeden in vier Darstellungen (832 Fälle) von 3 Review-Agenten mit 6 Modellkonfigurationen prüfen. Wurden die Pull Requests einzeln geprüft, fanden die Agenten 50 % bis 60 % der Angriffe; wurden 24 Pull Requests auf einmal geprüft, sank die Quote auf 16 % bis 22 %. Den Angriff in eine echte Änderung zu packen und eine glaubwürdige Beschreibung zu schreiben, die beides erklärt, senkte die Trefferquote um 10 bis 18 Prozentpunkte. Den Angriff auf mehrere Commits zu verteilen, machte höchstens 5 Prozentpunkte aus.

Die Autoren schließen: Verschleierung wirkt am besten, wenn harmlose und bösartige Änderungen zusammen vor dem Prüfer liegen oder wenn der in der Beschreibung genannte Zweck den Diff plausibel aussehen lässt. In der Liste aus dem Beitrag über das Review von KI-generiertem Code gibt es dafür einen Punkt: Jede Behauptung der Beschreibung muss eine Entsprechung im Diff haben. Fragen Sie nach PRWeaver auch umgekehrt: Hat jede Änderung im Diff einen Grund in der Beschreibung?

Dauerhaft steuern lässt sich ein Review-Bot, indem man seine Regeln ändert. Wird die Regeldatei aus dem Branch des Pull Requests gelesen, kann der Pull Request auch die Regeln seines eigenen Reviews ändern. Die Dokumentation der Tools sagt dazu Unterschiedliches:

Quelle: Dokumentation der Tools, 20. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu.

Ein Beispiel dafür, wie man die Rechte des Agenten eng hält, sind GitHub Agentic Workflows: Der Agent läuft nur mit Leserechten, und Schreibvorgänge wie ein Pull Request, den er öffnen will, werden nicht sofort ausgeführt, sondern zurückgehalten. Laut Dokumentation läuft vorher ein eigener Job, der die Ausgabe nach Versuchen von Prompt Injection, durchgesickerten Secrets und bösartigem Code durchsucht. Ein getäuschter Agent kann nur so viel Schaden anrichten, wie die Rechte zulassen, die Sie ihm geben.

Was tun bei einem unbekannten Repository oder Pull Request?

Kurz gesagt: Die Vertrauensabfrage kommt einmal, in CI nie, und den Text filtert sie nicht. Was Sie tun sollten, hängt vom Fall ab:

• Ein Repository, das Sie nicht kennen. Vertrauen Sie ihm nicht. VS Code empfiehlt, den Ordner im Zweifel im Restricted Mode zu lassen, Cursor, ein Repository, dem Sie nicht vertrauen, in einem einfachen Texteditor zu öffnen. Wenn Sie mit einem Agenten daran arbeiten müssen, öffnen Sie es in einer virtuellen Maschine oder einem Container; auch die Dokumentation von Claude Code empfiehlt virtuelle Maschinen. Eine Sandbox allein reicht nicht: In Claude Code deckt die Sandbox nur Shell-Befehle ab, Hooks und MCP-Server bleiben außen vor. Mehr dazu im Beitrag über die Sandbox.
• Ein Ordner aus zweiter Hand. Enthält ein Ordner, der als Zip, über ein gemeinsames Laufwerk oder auf einem USB-Stick kam, einen .git-Ordner, lesen Sie wie von Manifold empfohlen die .git/config, bevor Sie ihn mit einem Agenten öffnen, oder klonen Sie das Repository neu von der Quelle.
• Ein Agent, der in CI Pull Requests aus Forks prüft. Lassen Sie den Agenten keine Projekteinstellungen laden: Übergeben Sie in Claude Code --setting-sources user, und nutzen Sie COPILOT_ALLOW_ALL in Copilot CLI und --trust in Cursor CLI nicht auf dem Branch des Pull Requests. Der Leitfaden von GitHub vom 7. Mai 2026 nennt permissions: read-all einen vernünftigen Standard und sagt, man solle die Ausgabe des Modells nie per eval ausführen. Legen Sie keine Secrets in den Schritt des Agenten.
• Ein Pull Request, der eine Einstellungs- oder Regeldatei ändert. Lesen Sie einen Diff, der eine der Dateien aus dem zweiten Abschnitt berührt, wie eine Sicherheitsänderung; auch der Leitfaden von GitHub wertet jede Änderung, die CI schwächt, als Blocker. Liest Ihr Review-Bot seine Regeln aus dem Branch des Pull Requests, bestimmt eine Änderung an der Regeldatei auch, wie dieser Pull Request geprüft wird; lesen Sie auch sie wie Code.

Dieselben Fragen haben wir unserem eigenen Review-Dienst gestellt. Unser Tool für KI-Code-Review, diffox, klont das Repository bei jedem Review neu von GitHub in einen leeren Ordner; weil ein Klon die .git/config nicht mitbringt, erreicht uns der Weg, den GitSpawn nutzte, nicht. Die Regeln werden, wie im Beitrag zur Architektur beschrieben, aus dem Branch gelesen, in den der Pull Request gemergt wird. Der Autor eines Pull Requests aus einem Fork kann den Diff und die Dateinamen frei schreiben; Text daraus, der in unseren Kommentar gelangt, kann aber weder ein HTML-Tag öffnen noch zum Link werden. Diese Regel soll verhindern, dass ein Phishing-Link unter unserem Namen erscheint, dass jemand den eingeklappten Abschnitt schließt und einen falschen Abschnitt „keine Probleme“ schreibt und dass über ein Bild Daten abfließen.

Häufige Fragen

Was ist Workspace Trust?

Ein Coding-Tool oder Editor fragt, wenn Sie einen Ordner zum ersten Mal öffnen, ob Sie ihm vertrauen, und lädt einen Teil der Einstellungen im Ordner erst, wenn Sie das tun. Das soll verhindern, dass Hooks, Tasks und MCP-Server, die jemand ins Repository gelegt hat, laufen, bevor Sie sie angesehen haben. Claude Code, Codex, GitHub Copilot, Cursor und Antigravity CLI haben es; im Editor von Cursor ist es standardmäßig aus. Vertrauen bekommt ein Ordner einmal, und es hindert den Text im Ordner nicht daran, den Agenten zu steuern.

Was schaltet das Vertrauen in einen Ordner in Claude Code frei?

Claude Code bindet das Vertrauen an die Wurzel des Repositorys, und es gilt für das ganze Repository. Danach werden die Allow-Regeln und zusätzlichen Verzeichnisse aus der .claude/settings.json des Projekts genutzt, ebenso Hooks und MCP-Server von Subagenten und Plugins aus dem Repository; auch die Hooks und der env-Block aus der Einstellungsdatei laufen in der Sitzung. Für Server aus .mcp.json gibt es eine eigene Abfrage. Die Abfrage erscheint nur in einer interaktiven Sitzung; claude -p und das SDK fragen nie. Starten Sie in Ihrem Home-Verzeichnis, gilt das Vertrauen nur für diese Sitzung.

Wie entferne ich einen vertrauenswürdigen Ordner wieder?

Das hängt vom Tool ab. In VS Code öffnen Sie den Workspace-Trust-Editor (Workspaces: Manage Workspace Trust) und entfernen den Ordner aus der Liste der vertrauenswürdigen Ordner. In Copilot CLI bearbeiten Sie die Liste trustedFolders in ~/.copilot/config.json. In Gemini CLI geben Sie in diesem Ordner /permissions ein; alle Entscheidungen stehen in ~/.gemini/trustedFolders.json. In Codex setzen Sie den trust_level dieses Projekts in ~/.codex/config.toml auf untrusted. Claude Code speichert das Vertrauen im Feld hasTrustDialogAccepted in ~/.claude.json; ein Befehl, um es zurückzunehmen, steht nicht in der Dokumentation. In der Dokumentation von Cursor und Antigravity steht dazu ebenfalls nichts.

Kann man Workspace Trust in VS Code ausschalten?

Ja: Die Einstellung security.workspace.trust.enabled (standardmäßig an) schaltet die Funktion ganz aus, der Schalter --disable-workspace-trust nur für diese Sitzung. VS Code selbst rät zum Gegenteil: Lassen Sie den Ordner im Zweifel im Restricted Mode; vertrauen können Sie später. Im Restricted Mode sind Agenten, Tasks, Debugging und Terminal aus. Sie können Repositorys, die Sie oft öffnen, unter einem übergeordneten Ordner sammeln und nur diesem Ordner vertrauen, und unbekannte Repositorys in einem anderen Ordner ablegen.

Was ist Prompt Injection?

Prompt Injection heißt, Anweisungen in einem Text zu verstecken, den ein Modell liest, um sein Verhalten zu ändern. OWASP unterscheidet zwei Arten: die direkte Prompt Injection über die eigene Eingabe des Nutzers und die indirekte Prompt Injection, versteckt in einer Webseite, einer Datei oder einem Kommentar, die das Modell von außen liest. Bei Coding-Agenten steht die zweite im Vordergrund: Eine Datei im Repository, die Beschreibung eines Pull Requests oder der Text eines Issues gelangt in den Kontext des Agenten. Laut OWASP muss der Text für Menschen nicht einmal sichtbar sein; es genügt, dass das Modell ihn liest.

Kann ein Pull Request ein KI-Code-Review-Tool täuschen?

Die Forschung zeigt: ja. In PRWeaver fanden KI-Review-Agenten 50 % bis 60 % der versteckten Angriffe, wenn Pull Requests einzeln geprüft wurden, und 16 % bis 22 %, wenn 24 Pull Requests zusammen geprüft wurden; eine glaubwürdige Beschreibung senkte die Quote weiter. In GitInject waren alle 4 getesteten Anbieter in ihrer Standardkonfiguration für mindestens eine Angriffsklasse anfällig. Prüfen Sie, ob Ihr Tool seine Regeln aus dem Branch des Pull Requests liest oder aus dem Branch, in den er gemergt wird. Bei diffox werden die Regeln aus dem Branch gelesen, in den gemergt wird, und Text aus dem Pull Request, der in seinen Kommentar gelangt, kann weder zum Tag noch zum Link werden.

Erscheint die Vertrauensabfrage bei claude -p oder in CI?

Nein. Laut der Dokumentation von Claude Code zeigen claude -p und SDK-Sitzungen die Vertrauensabfrage nie; die Hooks aus der Einstellungsdatei des Repositorys, der env-Block und apiKeyHelper werden genutzt, und Server aus .mcp.json verbinden sich ohne Rückfrage. Starten Sie in einem Repository, das Sie nicht geschrieben haben, mit --setting-sources user oder --bare; um Hooks abzuschalten, übergeben Sie disableAllHooks mit --settings. Der -p-Modus von Copilot CLI lädt in einem nicht vertrauenswürdigen Ordner keine Hooks aus dem Repository; Cursor CLI bricht ab, solange Sie nicht --trust übergeben.