Eine Agentensitzung im zweiten VS-Code-Fenster weiterzuführen, klingt zunächst nach einer kleinen Komfortfunktion. In VS Code 1.129 macht sie im Arbeitsalltag einen Unterschied: Der Agent Host hält die Sitzung in einem eigenen Prozess, während mehrere Fenster darauf zugreifen können. Das ersetzt weder sorgfältige Freigaben noch einen Blick auf Git-Diff und Rechte.
Das Wichtigste in 30 Sekunden
- VS Code 1.129 erschien am 15. Juli 2026; die Release-Notiz nennt 1.129.1 als Download-Version.
- Der Agent Host kann eine Sitzung unabhängig vom sichtbaren Fenster führen und in mehreren VS-Code-Fenstern verfügbar machen.
- Mit
!vor einer Chatnachricht lässt sich deren Inhalt in einer Agent-Host-Sitzung als Terminalbefehl ausführen. - Der eigene Host-Prozess ist keine Sicherheits-Sandbox. Rechte, Workspace Trust und die Prüfung jeder Änderung bleiben separate Aufgaben.
Voraussetzungen, Dauer und Schwierigkeit
Für den Test braucht es VS Code 1.129 beziehungsweise 1.129.1, einen verfügbaren Agent-Host-Harness, ein kleines Test-Repository und Git. Sinnvoll sind 15 bis 25 Minuten ohne Zeitdruck. Die Schwierigkeit ist mittel: Der Klickweg ist überschaubar, doch die Grenzen zwischen gemeinsamer Sitzung, Berechtigungen und echter Isolation sollten klar bleiben.
Die Funktion wird laut Microsoft schrittweise aktiviert. Fehlt chat.agentHost.enabled oder kein Harness lässt sich auswählen, ist das kein Anlass für verdeckte Workarounds. Dann endet der Test an dieser Stelle. Für Teams in Deutschland und Europa gilt derselbe praktische Maßstab wie überall: Repository-Regeln, Zugriffsrechte und ein überprüfbarer Rückkehrpunkt gehören vor den ersten Agentenlauf.
So testen Sie die geteilte Sitzung kontrolliert
- Test-Repository wählen. Nutzen Sie keinen Produktivzweig und keinen Ordner mit Secrets. Öffnen Sie ein kleines Repository oder einen frischen Worktree und lesen Sie zuerst
git status. - Workspace Trust bewusst prüfen. Bei einem unbekannten Ordner bleibt Restricted Mode die vernünftige Voreinstellung. Vertrauen Sie den Workspace erst, wenn Herkunft und Inhalt geprüft sind. Der Trust-Status wird zwischen Editor und Agents-Fenster geteilt.
- Version und Verfügbarkeit kontrollieren. Prüfen Sie die installierte Version und suchen Sie nach
chat.agentHost.enabled. Aktivieren Sie die Einstellung nur, wenn sie vorhanden ist, und wählen Sie einen verfügbaren Agent-Host-Harness. - Sitzung im Agents-Fenster starten. Wählen Sie dort New, anschließend Ordner oder Repository, Agenttyp sowie bei Bedarf die Berechtigungsebene. Für den dokumentierten Copilot-Pfad kann ein neuer Worktree eine optionale Isolation schaffen.
- Dasselbe Gespräch im zweiten Fenster öffnen. Wechseln Sie in das Hauptfenster und prüfen Sie, ob Verlauf und Sitzungszustand übereinstimmen. Das ist ein Sicht- und Übergabetest. Er beweist keine Sperren für gleichzeitige Änderungen an derselben Datei.
!nur mit einem lesenden Befehl ausprobieren. Senden Sie etwa!git status. Lesen Sie den Befehl vorher vollständig, beachten Sie die sichtbare Berechtigungsanzeige und kopieren Sie keine sensiblen Ausgaben in den Chat.- Arbeitsbaum prüfen und zurückkehren. Kontrollieren Sie danach Status und Diff. Wenn mehrere Personen oder Fenster am selben Projekt arbeiten, sollte nur eine Instanz denselben Datei- oder Modulbereich schreiben.
Prüfpunkte: Was sichtbar sein sollte – und wann der Test endet
| Prüfpunkt | Erwartetes Ergebnis | Abbruchsignal |
|---|---|---|
| Version und Rollout | 1.129/1.129.1 sowie die nötige Option sind vorhanden. | Setting oder Harness fehlen. |
| Workspace Trust | Herkunft des Projekts ist geprüft und der Modus bewusst gewählt. | Unbekannter Inhalt oder ungeklärte Repository-Herkunft. |
| Zweites Fenster | Dieselbe Sitzung ist sichtbar und der Verlauf nachvollziehbar. | Es erscheint eine andere Sitzung oder der Zustand bleibt unklar. |
!git status |
Der lesende Befehl ist verständlich und sein Ergebnis passt zum Arbeitsbaum. | Der Befehl würde schreiben, Netzwerke ansprechen oder Geheimnisse ausgeben. |
| Git-Diff | Keine unerwarteten Änderungen oder jede Änderung ist bewusst geprüft. | Unklare Änderungen oder zwei schreibende Instanzen im selben Bereich. |
Vor einem !-Befehl
- Ist der vollständige Befehl lesbar und sein Zweck klar?
- Auf welcher Maschine läuft die Sitzung: lokal oder nahe einem Remote-Workspace?
- Stimmt das Arbeitsverzeichnis, und enthält es keine Secrets?
- Welche Berechtigungsstufe, Freigaben oder Auto-Approval-Regeln gelten?
- Ist klar, wie Status, Diff und der Ausgangszustand anschließend geprüft werden?
Woran Sie erkennen, dass der Test bestanden ist
Das Ergebnis ist gut genug, wenn dieselbe Sitzung in beiden Fenstern erkennbar bleibt, !git status nachvollziehbar ausgeführt wurde und der Arbeitsbaum anschließend unverändert oder bewusst geprüft ist. Ebenso wichtig: Das Team kann benennen, wer Änderungen schreiben darf und wie ein unerwarteter Diff behandelt wird. Der Mehrfensterbetrieb wird damit zu einer nachvollziehbaren Übergabe, nicht zu einer Einladung für parallele Schreibzugriffe.
Bei einem Remote Agent Host liegen Befehle und Dateiänderungen auf der Remote-Maschine nahe am Workspace. Das sollte vor dem Test ausdrücklich klar sein. Ein eigener Prozess verbessert die Sitzungsarchitektur und kann blockierende Extensions entkoppeln; eine allgemeine Rechtebarriere folgt daraus nicht.
Typische Fehler
Häufig scheitert der Versuch nicht an Git, sondern an einer falschen Erwartung. Ein fehlender Rollout oder Harness ist kein Fehler der lokalen Konfiguration, den man mit improvisierten Einstellungen umgehen sollte. Ebenso problematisch ist es, den getrennten Prozess als Sandbox zu lesen. Microsoft dokumentiert Approvals, Auto-Approval und mögliche Sandbox-Regeln als eigene, konfigurationsabhängige Steuerungen.
Ein weiterer Stolperstein ist die Oberfläche: Das Agents-Fenster ist Preview, Editor Panel und Modern UI sind experimentell. Für einen belastbaren Test reichen die dokumentierten Wege. Wer gleichzeitig zwei Fenster in denselben Dateien schreiben lässt, erzeugt außerdem ein eigenes Konfliktrisiko, das die gemeinsame Sitzung nicht auflöst.
FAQ
Warum sehe ich die Agent-Host-Einstellung noch nicht?
Microsoft aktiviert Agent Host und AHP schrittweise. Prüfen Sie Version, Einstellung und verfügbaren Harness. Fehlt einer dieser Punkte, warten Sie auf die Verfügbarkeit statt einen nicht dokumentierten Umweg zu nutzen.
Ist ein Agent Host sicherer als eine normale Sitzung?
Er trennt den Agentenprozess von ausgelasteten Extensions und hält die Sitzung unabhängig vom Client. Das ist kein Beleg für eine Sandbox. Rechte, Trust, Freigaben und Review bleiben erforderlich.
Dürfen zwei Fenster dieselbe Datei ändern?
Die Quellen belegen eine gemeinsame, synchronisierte Sitzung, keine konfliktfreie parallele Bearbeitung. Legen Sie deshalb pro Datei- oder Modulbereich eine schreibende Instanz fest.
Wie kehre ich zum normalen Ablauf zurück?
Deaktivieren Sie den Opt-in, schließen Sie die Test-Sitzung und prüfen Sie den Git-Status. Änderungen bleiben erst dann unkritisch, wenn sie im Diff verstanden oder verworfen wurden.
Weiterlesen
Quellen und weiterführende Informationen
- Microsoft: Visual Studio Code 1.129
- Microsoft: VS Code Agent Host architecture
- Microsoft: Use the Agents window (Preview)
- Microsoft: Manage approvals and permissions
- Microsoft: Workspace Trust
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-07-22
