VS Code 1.141 schützt und koordiniert Agenten besser
Das Update verbindet Terminal-Sandboxing, steuerbare Unterhaltungen mit Unteragenten und eine vorsichtige Bereinigung inaktiver Worktrees.
Mit Visual Studio Code 1.141, veröffentlicht am 7. Oktober 2026, bekommt die Arbeit mit Coding-Agenten drei eng zusammenhängende Ergänzungen: eine plattformübergreifende Terminal-Sandbox, besser sichtbare verschachtelte Sitzungen und Werkzeuge zum Aufräumen inaktiver Agent-Worktrees. Der neue Baustein ist damit nicht einfach ein weiterer Chat-Schalter. VS Code kümmert sich stärker darum, was parallel arbeitende Agenten erreichen dürfen, wie sie untereinander koordiniert werden und welche Arbeitskopien nach erledigten Aufgaben zurückbleiben.
Das ist besonders bei Aufgaben interessant, die sich sinnvoll teilen lassen. Ein Hauptagent kann beispielsweise eine Änderung am Anwendungscode bearbeiten, während Unteragenten Tests oder Dokumentation untersuchen. Die neue Sitzungsverwaltung macht diese Verzweigung sichtbar; die Sandbox begrenzt Terminalaktionen; die Worktree-Verwaltung hilft anschließend, nicht mehr benötigte Arbeitskopien wiederzufinden. Die drei Funktionen lösen unterschiedliche Probleme und sollten deshalb auch getrennt konfiguriert werden.
Verschachtelte Sitzungen bleiben sichtbar
Unteragenten verschwinden in Version 1.141 nicht mehr so leicht hinter der Hauptunterhaltung. Verschachtelte Sitzungen erhalten laut den Release Notes eine eigene Anzeige für Aktivität und Lesestatus. Dadurch lässt sich erkennen, ob eine delegierte Unterhaltung noch arbeitet und ob neue Ergebnisse vorliegen, ohne jede Sitzung einzeln auf Verdacht zu öffnen.
Der praktische Gewinn zeigt sich bei einer aufgeteilten Codeänderung. Angenommen, der Hauptagent passt eine Schnittstelle an und übergibt zwei Nebenaufgaben: Ein Unteragent sucht betroffene Tests, ein anderer prüft die Dokumentation. Die Statusanzeigen trennen laufende, ungelesene und bereits gesichtete Arbeit. Das ersetzt keine fachliche Prüfung der Ergebnisse, beseitigt aber einen blinden Fleck der parallelen Agentennutzung: Der Mensch sieht, wo sich noch etwas bewegt und wo eine Antwort auf Aufmerksamkeit wartet.
Auch die Hierarchie bleibt fachlich nützlich. Eine Testsitzung gehört erkennbar zur übergeordneten Änderung, statt als unabhängiger Chat neben vielen anderen Unterhaltungen zu stehen. Damit wird die Sitzungsansicht zur Orientierung über zusammengehörige Aufgaben und nicht bloß zu einer längeren Chronik.
send_message korrigiert einen Agenten während der Arbeit
Neu ist außerdem die Kommunikation mit laufenden Sitzungen über send_message. Nach Angaben der Release Notes können aktive Unterhaltungen damit korrigiert werden. Für vorgemerkte Nachrichten gibt es mehr Kontrolle: Sie lassen sich hinzufügen, ersetzen oder abbrechen.
Das ist mehr als ein Komfortdetail. Stellt ein Hauptagent während einer Änderung fest, dass ein Unteragent die falsche Testdatei untersucht, muss dessen gesamte Sitzung nicht verworfen werden. Eine Nachricht kann die laufende Suche auf das richtige Modul lenken. Liegt bereits eine Anweisung in der Warteschlange, lässt sie sich austauschen, bevor sie verarbeitet wird. Und wenn ein Ergebnis eines anderen Unteragenten die Aufgabe überflüssig macht, kann die vorgemerkte Nachricht abgebrochen werden.
So entsteht eine konkrete neue Möglichkeit gegenüber einer starren Delegation: Aufgeteilte Arbeit bleibt während ihrer Ausführung korrigierbar. Besonders nützlich ist das bei Abhängigkeiten zwischen Teilaufgaben. Wenn der Agent für den Anwendungscode etwa einen Funktionsnamen ändert, kann der Hauptagent diese Information unmittelbar an die Sitzung für Tests weiterreichen. send_message ist dabei die Kommunikationsfunktion; Datei- oder Netzwerkrechte erweitert sie nicht.
Die Sandbox begrenzt Terminalbefehle und Kindprozesse
Das Sandboxing für Copilot-Agent-Host-Sitzungen beschränkt Terminalbefehle auf konfigurierte Dateisystem- und Netzwerkressourcen. Die Regeln erfassen auch Kindprozesse eines Befehls. Startet ein Agent etwa über ein Skript einen Paketmanager, einen Testprozess oder ein weiteres Kommando, endet die Begrenzung nicht automatisch am ersten Shell-Aufruf.
Nach der Dokumentation können außerdem MCP-Server und Sprachserver einbezogen werden, wenn sie vom Agent Host gestartet wurden. Das ist relevant, weil eine Agentensitzung nicht ausschließlich aus sichtbaren Terminalzeilen besteht. Ein vom Host gestarteter Hilfsdienst kann ebenfalls Dateien lesen oder Verbindungen aufbauen. Die Sandbox zieht den kontrollierten Bereich deshalb um mehr als nur den unmittelbar eingegebenen Befehl.
Ein sinnvolles Anwendungsszenario ist ein Agent, der Tests in einem Repository ausführt. Der benötigte Projektbereich kann beschreibbar bleiben, während andere Dateisystembereiche außerhalb seiner Aufgabe gesperrt werden. Für eine Abhängigkeitsinstallation lassen sich erforderliche Netzwerkziele zulassen, ohne daraus automatisch freien Zugriff auf jedes Ziel abzuleiten. Die konkrete Richtlinie muss zur Aufgabe passen: Ein reiner Testlauf braucht andere Rechte als eine Aktualisierung von Paketen.
Netzwerkzugriff wird nicht automatisch streng
Die Bezeichnung Sandbox darf nicht mit vollständiger Isolation verwechselt werden. Microsoft beschreibt sie ausdrücklich weder als virtuelle Maschine noch als eigenständige Sicherheitsgrenze. Vor allem der Netzwerkstandard verdient Aufmerksamkeit: Ausgehender Zugriff ist zunächst erlaubt. Wer eine Sitzung enger begrenzen will, muss den Netzwerkzugriff separat deaktivieren oder über Domainregeln einschränken.
Für das Testbeispiel bedeutet das: Eine Dateisystemregel allein verhindert nicht, dass ein gestartetes Werkzeug eine externe Adresse kontaktiert. Soll der Agent ausschließlich mit dem lokalen Repository arbeiten, gehört auch die ausgehende Verbindung in die Richtlinie. Benötigt ein Paketmanager eine Registry, kann die Freigabe auf das erforderliche Ziel zugeschnitten werden. Die Sandbox liefert dafür die Begrenzung, errät aber nicht, welche externen Dienste fachlich notwendig sind.
Die Plattformdetails unterscheiden sich ebenfalls. Die Funktion wird für Windows, macOS und Linux eingeführt; laut Sandboxing-Dokumentation benötigen Linux und WSL2 bubblewrap und socat. Die Windows-Unterstützung ist als experimentell gekennzeichnet. Gerade auf gemischten Entwicklungsrechnern sollte daher nicht aus derselben Einstellung automatisch auf identisches technisches Verhalten geschlossen werden.
Freigaben und Sandbox erfüllen verschiedene Aufgaben
VS Code trennt Aktionsfreigaben und Berechtigungen von der Sandbox. Freigaben entscheiden, ob eine Aktion vor ihrer Ausführung bestätigt werden muss. Die Sandbox bestimmt dagegen, auf welche Dateien und Netzwerkressourcen Terminalbefehle tatsächlich zugreifen dürfen. Eine großzügige Bestätigungsstufe hebt die Ressourcenbegrenzung nicht auf.
Das gilt ausdrücklich auch für Allow all und Autopilot: Die Sandbox bleibt in diesen Berechtigungsstufen wirksam. Damit lassen sich zwei Entscheidungen unabhängig treffen. Ein Agent kann Terminalaktionen ohne wiederholte Rückfrage ausführen und trotzdem nur innerhalb der eingerichteten Datei- und Netzwerkgrenzen arbeiten. Umgekehrt macht eine häufige Nachfrage eine zu weit gefasste Sandbox nicht automatisch enger.
Eine weitere Trennlinie betrifft Aktionen außerhalb des Terminals. Für sie sind weiterhin Werkzeug- und URL-Freigaben erforderlich. Wer die Einstellungen prüft, sollte deshalb nach dem Ausführungskanal unterscheiden: Terminalbefehl, vom Agent Host gestarteter Dienst oder anderes Werkzeug. Eine einzige globale Vorstellung von „erlaubt“ bildet diese Ebenen nicht korrekt ab.
Alte Agent-Worktrees lassen sich gezielt finden
Parallele Agentensitzungen können eigene Git-Worktrees erzeugen. Das hält Änderungen voneinander getrennt, verbraucht aber mit der Zeit Speicher und hinterlässt zusätzliche Arbeitskopien. Der Editor zur Verwaltung von Agentensitzungen kann Worktrees nach 7, 15, 30, 60 oder 90 Tagen Inaktivität filtern und zeigt ihren geschätzten Speicherbedarf.
Damit wird eine bislang leicht übersehene Nebenwirkung autonomer Aufgaben messbar. Statt Verzeichnisse anhand ihres Namens oder Alters manuell zu erraten, kann man alte Arbeitskopien nach einem definierten Zeitraum auswählen und ihren Platzbedarf vor der Bereinigung einschätzen. Für häufige, kleine Agentenaufgaben eignet sich ein kürzerer Filter; bei länger laufenden Vorhaben lassen sich 60 oder 90 Tage wählen.
Die automatische Bereinigung zusammengeführter Sitzungen ist als Preview verfügbar und standardmäßig deaktiviert. Sie ist daher kein stillschweigend aktiver Hintergrunddienst. Wer sie nutzen möchte, entscheidet sich bewusst dafür und beschränkt die Automatik auf Sitzungen, deren Änderungen bereits zusammengeführt wurden.
Git-Zustände schützen vor vorschnellem Löschen
Beim Aufräumen setzt VS Code bewusst nicht auf erzwungenes Entfernen. Ein Worktree bleibt erhalten, wenn sein Git-Zustand unbekannt ist, wenn ausgehende Commits existieren oder wenn Änderungen noch nicht eingecheckt wurden. Diese Schutzregeln sind entscheidend, weil Inaktivität allein nichts darüber aussagt, ob eine Arbeitskopie entbehrlich ist.
Ein konkretes Beispiel: Ein Unteragent hat eine brauchbare Anpassung erstellt, sie aber weder eingecheckt noch in den Hauptzweig übernommen. Selbst wenn die Sitzung später in den gewählten Altersfilter fällt, darf die Bereinigung diese Änderung nicht wie einen leeren Rest behandeln. Dasselbe gilt für lokale Commits, die noch nicht im erwarteten Ziel angekommen sind. Der Bereinigungseditor verbindet deshalb Alter und Speicherbedarf mit dem tatsächlichen Git-Zustand.
Die automatische Funktion eignet sich vor allem für eindeutig zusammengeführte Sitzungen. Arbeitskopien mit unklarem Zustand bleiben eine bewusste Entscheidung. So reduziert das Update Speicherreste, ohne die Trennung durch Worktrees in ein Löschrisiko für noch nicht übernommene Arbeit zu verwandeln.
So nutzt man die Neuerungen zusammen
Für eine größere Änderung bietet sich folgende Kombination an: Der Hauptagent behält die zentrale Codeaufgabe, während klar abgegrenzte Untersuchungen in verschachtelten Sitzungen landen. Aktivitäts- und Lesestatus zeigen, welche Teilaufgabe noch läuft. Ändert sich eine Vorgabe, erreicht die Korrektur den zuständigen Unteragenten über send_message, statt eine neue parallele Unterhaltung zu eröffnen.
Vor Terminalaktionen wird festgelegt, welche Projektbereiche die Sitzung benötigt. Netzwerkzugriff wird separat behandelt, weil er standardmäßig erlaubt bleibt. Soll ein Agent nur lokale Tests ausführen, kann ausgehender Zugriff abgeschaltet werden; benötigt er eine Registry oder einen bestimmten Dienst, lassen sich passende Domainregeln setzen. Die Aktionsfreigabe wird unabhängig davon gewählt und ersetzt diese Grenzen nicht.
Nach Abschluss bleiben die Git-Ergebnisse maßgeblich. Zusammengeführte Sitzungen können über die zunächst deaktivierte Preview automatisch bereinigt werden. Andere Worktrees werden nach Inaktivität und Speicherbedarf gesichtet. Nicht eingecheckte Änderungen, ausgehende Commits und unbekannte Zustände bleiben erhalten. So greifen Koordination, Zugriffsschutz und Speicherpflege ineinander, ohne dieselbe Aufgabe zu übernehmen.
Verfügbarkeit und passendes Einsatzprofil
Der Agentenmodus in VS Code ist laut GitHub Copilot Plans in allen Individualtarifen enthalten. Copilot Free kostet 0 US-Dollar und umfasst eine begrenzte Chat- und Agentennutzung. Copilot Pro kostet 10 US-Dollar, Pro+ 39 US-Dollar und Max 100 US-Dollar pro Nutzer und Monat; Umfang und verfügbare AI Credits unterscheiden sich je Tarif.
Den größten Nutzen hat Version 1.141 dort, wo Agenten tatsächlich Terminalbefehle ausführen, Teilaufgaben parallel bearbeiten und isolierte Worktrees anlegen. Für eine einzelne kurze Chatfrage bleibt der zusätzliche Verwaltungsbedarf gering. Bei mehreren gleichzeitig arbeitenden Sitzungen werden dagegen genau die Punkte sichtbar, auf die das Update zielt: laufende Unterhaltungen müssen auffindbar sein, Korrekturen müssen den richtigen Agenten erreichen, Terminalrechte brauchen nachvollziehbare Grenzen und abgeschlossene Arbeitskopien dürfen nicht unbegrenzt Speicher belegen.
Die wichtige Einordnung lautet deshalb: VS Code 1.141 macht Agenten nicht automatisch sicher und räumt auch nicht bedenkenlos alles Alte weg. Es stellt getrennte, konkret steuerbare Mechanismen bereit. Wer Dateirechte, ausgehende Verbindungen, Aktionsfreigaben und Git-Zustände jeweils an der richtigen Stelle behandelt, kann mehr parallele Agentenarbeit zulassen, ohne Übersicht und lokale Ressourcen vollständig aus der Hand zu geben.