Wer in Visual Studio Code einen fremden Ordner öffnet, sieht oft eine Meldung wie: „Do you trust the authors of the files in this folder?“ Viele bestätigen sie reflexartig. Genau das ist riskant. Hinter der Abfrage steckt keine lästige Komfortfunktion, sondern ein Schutzmechanismus für Ihre Arbeitsumgebung.

Im Alltag sprechen viele von „Trust Directory“ in VS Code. Der offizielle Name lautet jedoch Workspace Trust. Die Funktion entscheidet nicht, ob ein Repository objektiv sicher ist. Sie steuert, ob VS Code bestimmte Funktionen für einen Ordner oder Workspace freigibt oder vorsorglich einschränkt.

Gerade für Admins, DevOps-Teams und Entwickler, die häufig fremde Repositories, ZIP-Dateien oder Demo-Projekte öffnen, lohnt sich ein genauer Blick auf diese Abfrage.

Was mit „Trust Directory“ in VS Code gemeint ist

Der Begriff „Trust Directory“ ist eher Umgangssprache. In der VS-Code-Dokumentation heißt die Funktion Workspace Trust. Gemeint ist also nicht einfach ein „vertrauenswürdiges Verzeichnis“, sondern ein Sicherheitsmodell für geöffnete Ordner, Workspaces und zum Teil auch einzelne Dateien.

VS Code verwaltet lokal, ob ein Ordner oder Workspace als vertrauenswürdig markiert wurde. Das ist ein wichtiger Unterschied: Der Editor führt keine Sicherheitsprüfung des Inhalts durch und bewertet auch nicht die Herkunft eines Projekts im Sinne eines Audits. Vertrauen bedeutet hier nur: Sie erlauben VS Code, die üblichen Workspace-Funktionen für diesen Pfad zu aktivieren.

Praktisch heißt das:

• Ein Ordner kann lokal als vertrauenswürdig gespeichert sein.
• Ein Workspace kann auf dieser Entscheidung aufbauen.
• Unterordner können Vertrauen vom übergeordneten Pfad erben.
• Einzelne Dateien außerhalb vertrauenswürdiger Ordner behandelt VS Code separat.

Wenn Sie also einen Unterordner öffnen und keinen eigenen „Don’t Trust“-Schalter sehen, liegt das oft daran, dass der Elternordner bereits als vertrauenswürdig gilt.

Warum ein Code-Editor überhaupt so eine Abfrage braucht

VS Code ist längst kein reiner Texteditor mehr. Die Umgebung kann mit Erweiterungen arbeiten, Tasks starten, externe Werkzeuge aufrufen, Debugging-Funktionen bereitstellen und Workspace-Einstellungen berücksichtigen. Genau an dieser Stelle beginnt das Sicherheitsproblem.

Ein fremdes Projekt kann Konfigurationen mitbringen, die Werkzeuge oder Abläufe anstoßen. Die offizielle Dokumentation nennt dabei ausdrücklich Funktionen rund um Kompilieren, Debuggen, Linting oder Formatieren. Es geht also nicht darum, dass jede Datei automatisch gefährlich ist. Es geht darum, dass ein geöffneter Workspace mehr tun kann als nur Text anzeigen.

Das Muster kennen Admins aus anderen Bereichen ebenfalls: Warnhinweise sind oft unbequem, aber sie verhindern, dass man einer Umgebung zu schnell Rechte gibt. Ein ähnliches Prinzip sehen Sie auch bei anderen Sicherheitsdialogen, etwa in unserem Beitrag zur Remote-Desktop-Sicherheitswarnung, bei der man ebenfalls nicht einfach reflexartig bestätigen sollte.

Was Workspace Trust konkret schützt

Workspace Trust soll vor allem verhindern, dass VS Code in unbekannten Projekten zu früh Funktionen freischaltet, die Code ausführen oder Workspace-Inhalte tief auswerten.

Dazu zählen laut Microsoft vor allem:

• Tasks und projektbezogene Abläufe
• Funktionen rund um Debugging, Build, Linting oder Formatierung
• Erweiterungen, die im Workspace aktiv werden
• Workspace-bezogene Einstellungen, die Verhalten von Erweiterungen oder Tools beeinflussen

Ein einfaches Beispiel ist eine tasks.json in einem Projekt. So eine Datei ist für sich genommen noch kein Problem. Kritisch wird es dann, wenn ein Benutzer einem unbekannten Projekt vertraut und VS Code daraufhin Funktionen freigibt, die externe Kommandos ausführen können.

Ein vereinfachtes Beispiel:

{
  "tasks": [
    {
      "label": "build",
      "command": "./build.sh"
    }
  ]
}

Dieses Beispiel soll nur das Prinzip zeigen. Es bedeutet nicht, dass jede Task sofort ohne Nachfrage startet. Im Restricted Mode blendet VS Code beim Ausführen oder sogar beim Auflisten von Tasks einen Vertrauensdialog ein.

Was im Restricted Mode passiert

Wenn ein Ordner nicht als vertrauenswürdig gilt, öffnet VS Code ihn im Restricted Mode. Das ist kein Totalausfall. Sie können Quellcode weiterhin lesen und bearbeiten. Der Modus soll Ihnen gerade ermöglichen, ein Projekt erst einmal anzusehen, bevor Sie ihm mehr Rechte geben.

Eingeschränkt werden vor allem Funktionen, die näher an Ausführung und Automatisierung liegen.

Typische Folgen im Restricted Mode:

• Quellcode lässt sich öffnen und editieren.
• Tasks werden nicht einfach ausgeführt; VS Code fragt nach Vertrauen.
• Manche Erweiterungen arbeiten nur teilweise oder gar nicht.
• Bestimmte workspace-definierte Einstellungen werden ignoriert oder begrenzt.
• Funktionen rund um Codeausführung können eingeschränkt sein.

Ein wichtiger Punkt: Es werden nicht pauschal alle Extensions deaktiviert. Das Verhalten hängt davon ab, ob eine Erweiterung Workspace Trust unterstützt und welche Funktionen ihr Autor im untrusted Kontext erlaubt hat. Manche Erweiterungen bleiben nutzbar, andere schalten nur ungefährliche Teile frei, wieder andere werden stark begrenzt.

Gerade in Teams mit vielen Plugins ist das relevant. Wenn eine Erweiterung im untrusted Kontext weniger kann als erwartet, liegt das nicht zwingend an einem Fehler. Oft ist genau das beabsichtigt.

Wann Sie einem Projekt vertrauen sollten

Im Alltag hilft eine einfache Frage: Würden Sie diesem Ordner auch dann Ausführungsrechte geben, wenn Sie seine Build- und Tooling-Konfiguration noch nicht kennen?

In vielen Fällen können Sie vertrauen, wenn es sich um Folgendes handelt:

• eigene Projekte
• bekannte interne Firmen-Repositories
• Arbeitsverzeichnisse aus einer klar geregelten Team-Umgebung
• Projekte bekannter Maintainer oder etablierter Organisationen, wenn Quelle und Inhalt nachvollziehbar sind

Zurückhaltend sollten Sie bei diesen Fällen sein:

• ZIP-Dateien aus Foren oder Chats
• Demo-Repositories aus unbekannten Quellen
• Gists oder Snippets mit unklarem Kontext
• Projekte mit vielen Build-Skripten und Tooling-Dateien, die Sie noch nicht gesehen haben
• kopierte Ordner aus Downloads oder temporären Ablagen

Auch der Übertragungsweg spielt eine Rolle. Wenn externe Projektdateien in Ihre Umgebung gelangen, sollte der Bezug nachvollziehbar und sicher sein. Das gilt nicht nur für Code, sondern generell für Dateien mit betrieblicher Relevanz. Dazu passt unser How-to zu SFTP mit OpenSSH auf Ubuntu, wenn Sie Dateien kontrolliert und ohne unsaubere Nebenwege austauschen möchten.

So verwalten Sie Workspace Trust in der Praxis

VS Code bietet mehrere Stellen, an denen Sie den Trust-Status prüfen oder ändern können.

Sie finden die Verwaltung unter anderem über:

• Workspaces: Manage Workspace Trust in der Command Palette
• das Banner im Restricted Mode
• die Statusleiste
• den Workspace-Trust-Editor mit der Liste Trusted Folders & Workspaces

Das ist im Alltag nützlich, wenn ein Pfad versehentlich als vertrauenswürdig gespeichert wurde oder wenn Sie eine Team-Struktur mit übergeordneten Ordnern nutzen. Gerade bei Parent-Trust lohnt sich ein kurzer Blick in die gespeicherten vertrauenswürdigen Pfade.

Ein typischer Fall aus der Praxis: Ein Entwickler markiert D:\Projekte als vertrauenswürdig. Danach erben viele Unterordner diesen Status. Öffnet er später ein neues Test-Repository in diesem Baum, erscheint kein gesonderter Warnhinweis mehr. Technisch ist das korrekt, organisatorisch kann es aber zu weit gefasst sein.

Diese Einstellungen sind für Admins besonders relevant

Die offizielle Dokumentation nennt mehrere Settings, mit denen Sie das Verhalten anpassen können:

• security.workspace.trust.enabled
• security.workspace.trust.startupPrompt
• security.workspace.trust.emptyWindow
• security.workspace.trust.untrustedFiles
• extensions.supportUntrustedWorkspaces
• security.workspace.trust.banner

Für die Praxis reichen meist diese Fragen:

Soll Workspace Trust überhaupt aktiv sein?

Das steuert security.workspace.trust.enabled. Sie können die Funktion auch ganz deaktivieren oder VS Code per CLI mit --disable-workspace-trust starten. Microsoft empfiehlt das nicht. Für produktive Admin- und Entwicklerumgebungen ist Abschalten nur selten eine gute Idee.

Wann soll VS Code nachfragen?

Mit security.workspace.trust.startupPrompt beeinflussen Sie, wie offensiv VS Code die Abfrage beim Start behandelt. Das ist interessant, wenn Sie viele Projektordner nacheinander öffnen und ein klareres Verhalten wünschen.

Wie geht VS Code mit leeren Fenstern um?

Ein leeres Fenster ohne geöffneten Ordner gilt standardmäßig als vertrauenswürdig. Das wirkt auf den ersten Blick banal, kann im Alltag aber relevant sein. Über security.workspace.trust.emptyWindow ändern Sie dieses Verhalten.

Wie verhalten sich einzelne Dateien außerhalb vertrauenswürdiger Ordner?

Genau dafür ist security.workspace.trust.untrustedFiles gedacht. VS Code kann solche Dateien getrennt behandeln und sie bei Bedarf in einem neuen Fenster im Restricted Mode öffnen.

Wie sichtbar soll der Status sein?

Mit security.workspace.trust.banner legen Sie fest, wie deutlich der Hinweis im Editor erscheint. In größeren Teams ist eine sichtbare Kennzeichnung oft sinnvoller als eine zu zurückhaltende Anzeige.

Besondere Fälle: leeres Fenster, einzelne Dateien und verwaltete Umgebungen

Ein paar Details fehlen in vielen Erklärungen, sind aber im Alltag nützlich.

Ein leeres VS-Code-Fenster ist standardmäßig vertrauenswürdig. Wer oft nur schnell Dateien vergleicht oder Snippets prüft, bemerkt das oft gar nicht.

Lose Dateien außerhalb eines vertrauenswürdigen Ordners behandelt VS Code separat. Je nach Einstellung kann der Editor sie in einem neuen Fenster im Restricted Mode öffnen.

Außerdem gibt es verwaltete Umgebungen, die VS Code automatisch als vertrauenswürdig behandelt. Die Dokumentation nennt hier zum Beispiel GitHub Codespaces oder das Attachen an einen laufenden Docker-Container. Das ist logisch, weil VS Code diese Umgebungen als bereits kontrolliert einordnet. Für lokale Ordner aus unbekannten Quellen gilt diese Annahme dagegen nicht.

Ein sinnvoller Umgang für Teams und Admins

Workspace Trust ist am wirksamsten, wenn Sie es nicht als Einzelentscheidung des Entwicklers betrachten, sondern als Teil Ihrer Workstation-Sicherheit.

Dazu gehören in der Praxis:

• klare Regeln für interne und externe Repositories
• nachvollziehbare Herkunft von Projektdateien
• sparsame Nutzung breit vertrauter Oberordner
• regelmäßige Prüfung von Erweiterungen und lokalen Entwicklerwerkzeugen
• kontrollierte Plattformen für Identitäten und Zugriffe

Wenn Sie solche Prozesse sauber aufbauen möchten, spielen auch Authentifizierung und Rollen eine Rolle. Im Umfeld zentral verwalteter Entwickler- und Admin-Zugänge kann ein System wie Authentik sinnvoll sein. Für den Blick auf Schwachstellen in betriebenen Umgebungen passt außerdem ein Werkzeug wie OpenVAS, weil sichere Workflows nicht erst im Editor beginnen.

Workspace Trust löst also kein Grundproblem allein. Die Funktion schließt aber eine häufig übersehene Lücke: den Moment, in dem ein Benutzer einem unbekannten Projekt zu schnell vertraut.

Wenn Sie solche Sicherheitsdetails im Admin-Alltag interessant finden, finden Sie im Blog von ADMIN INTELLIGENCE weitere praxisnahe Beiträge rund um Security, DevOps und sichere Betriebsumgebungen. Wenn Sie Unterstützung beim Aufbau einer kontrollierten Entwickler- oder Repository-Umgebung benötigen, erreichen Sie uns auch direkt über unsere Kontaktseite.