VS Code 1.138: Agent-Sitzungen arbeiten jetzt im Dev Container
Der Agent Host kann direkt in der Projektumgebung laufen und dort auf deren Werkzeuge, Abhängigkeiten und Laufzeiten zugreifen.
Mit Visual Studio Code 1.138 können Agent-Sitzungen in einem lokalen Dev Container ausgeführt werden. Das ist mehr als eine neue Startoption: Der Agent bekommt damit dieselbe technische Umgebung wie das Projekt, einschließlich der dort installierten Werkzeuge und Abhängigkeiten. Die Bedienoberfläche bleibt lokal, während die eigentliche Ausführung in den Container wandert.
Die Neuerung adressiert eine typische Reibungsstelle bei Coding-Agenten. Zugriff auf Dateien allein reicht nicht, wenn ein Befehl eine bestimmte Laufzeit, ein Systempaket oder ein projektspezifisches Werkzeug benötigt. Läuft der Agent Host im Dev Container, werden Dateioperationen und Kommandos genau dort ausgeführt, wo diese Voraussetzungen bereits definiert sind. Microsoft führt die Funktion in VS Code 1.138 schrittweise ein; deshalb kann die Option trotz korrekter Vorbereitung noch nicht in jeder Installation sichtbar sein.
Was mit Version 1.138 neu hinzukommt
Bisher konnten Agent-Sitzungen über das Agents-Fenster gestartet und über mehrere Arbeitsbereiche hinweg beobachtet werden. Version 1.138 ergänzt für geeignete lokale Projektordner die Aktion „Use Dev Container“. Sie verlagert den Agent Host in den vorhandenen Projektcontainer, statt ihn in der lokalen Umgebung des Rechners auszuführen.
Diese Trennung ist wichtig: Das Agents-Fenster bleibt auf dem lokalen Rechner und dient weiterhin zum Starten, Überwachen und Prüfen der Sitzungen. Der Agent Host ist dagegen ein separater Prozess. Er verwaltet die Sitzung unabhängig von dem VS-Code-Fenster, in dem sie gerade angezeigt wird. Bei der neuen Startart befindet sich dieser Prozess im Container. Dadurch folgen seine Befehle, Pfade und verfügbaren Programme der Container-Konfiguration des Projekts. Die Architektur beschreibt Microsoft in der Dokumentation zum VS Code Agent Host.
Der Container wird damit nicht bloß zu einem Ziel für einzelne Terminalbefehle. Er ist die Arbeitsumgebung der gesamten Agent-Sitzung. Das betrifft sowohl Änderungen an Dateien als auch Kommandos, die der Agent während einer Aufgabe ausführt.
Warum der Ausführungsort einen Unterschied macht
Ein Repository kann präzise festlegen, welche Laufzeit, Bibliotheken und Systemwerkzeuge für seine Bearbeitung benötigt werden. Ohne diese Umgebung kann ein Agent den Quelltext zwar verändern, aber nachgelagerte Befehle können an fehlenden Programmen oder abweichenden Versionen scheitern. Eine lokale Installation kann außerdem anders konfiguriert sein als das Projekt.
Ein Dev Container bündelt diese Voraussetzungen in einer projektspezifischen Entwicklungsumgebung. Wenn der Agent Host dort läuft, sieht er nicht nur dieselben Dateien wie die Entwicklerinnen und Entwickler, sondern führt seine Befehle auch innerhalb dieses definierten Kontexts aus. Ein im Container installiertes Prüfwerkzeug ist für die Sitzung verfügbar; ein ausschließlich auf dem Host vorhandenes Programm gehört dagegen nicht automatisch zu ihrer Umgebung.
Das verändert vor allem Aufgaben, bei denen Codeänderung und Ausführung eng zusammengehören. Der Agent kann beispielsweise eine betroffene Datei bearbeiten und anschließend die im Container verfügbaren Projektbefehle aufrufen. Entscheidend ist nicht, dass der Agent dadurch neue Fähigkeiten erlernt. Neu ist, dass seine vorhandenen Fähigkeiten mit der tatsächlichen Projektumgebung verbunden werden.
Ein Beispiel: Änderung und Prüfung in derselben Umgebung
Angenommen, ein Projekt enthält bereits eine Dev-Container-Konfiguration und benötigt mehrere Werkzeuge, die nicht global auf dem Rechner installiert sind. Eine Agent-Sitzung außerhalb dieses Containers könnte den Code lesen und bearbeiten, hätte aber keinen verlässlichen Zugriff auf diese projektspezifische Ausstattung.
Mit „Use Dev Container“ startet der Agent Host innerhalb der vorbereiteten Umgebung. Die Sitzung kann dort eine Änderung anlegen und die Befehle verwenden, die der Container bereitstellt. Pfade, Laufzeiten und Abhängigkeiten entsprechen dabei der Container-Sicht auf den Arbeitsbereich. Das reduziert die Lücke zwischen einer vorgeschlagenen Änderung und ihrer Ausführung in der vorgesehenen Entwicklungsumgebung.
Die Funktion ersetzt allerdings nicht die Konfiguration des Projekts. Alles, was der Agent benötigt, muss bereits im Dev Container vorhanden oder dort regulär verfügbar sein. Ist ein Werkzeug nicht Bestandteil der Umgebung, entsteht es durch die neue Startart nicht automatisch. Der praktische Gewinn kommt gerade daher, dass eine vorhandene, reproduzierbare Projektumgebung nun auch zum Ausführungsort der Agent-Sitzung wird.
So startet eine Sitzung im Dev Container
Der Einstieg erfolgt ausschließlich über das als Vorschau gekennzeichnete Agents-Fenster. Laut Dokumentation des Agents-Fensters müssen drei Voraussetzungen erfüllt sein: Docker läuft auf dem lokalen Rechner, das Projekt besitzt eine Dev-Container-Konfiguration und die VS-Code-Einstellung chat.agentHost.devContainer.enabled ist aktiviert.
Anschließend wird im Agents-Fenster eine neue Sitzung für einen geeigneten lokalen Ordner angelegt und „Use Dev Container“ als Umgebung ausgewählt. Das Agents-Fenster bleibt lokal geöffnet. VS Code startet den Agent Host dagegen im Projektcontainer, von wo aus dieser auf den Container-Arbeitsbereich zugreift.
Die schrittweise Einführung kann dazu führen, dass die Aktion noch nicht erscheint, obwohl Docker, Projekt und Einstellung vorbereitet sind. Das ist Teil des von Microsoft beschriebenen Rollouts. Die Funktion ist zudem als Preview einzuordnen, weil das Agents-Fenster selbst in der Dokumentation entsprechend gekennzeichnet ist.
„Use Dev Container“ und „New Worktree“ sind Alternativen
Eine wichtige Grenze betrifft die Isolation von parallelen Änderungen. Dev-Container-Sitzungen greifen direkt auf den Arbeitsbereich im Container zu. Deshalb lassen sie sich nicht mit der Option „New Worktree“ kombinieren. Die beiden Optionen beantworten unterschiedliche Fragen: „Use Dev Container“ bestimmt die technische Ausführungsumgebung, während „New Worktree“ einen getrennten Git-Arbeitsbaum für die Sitzung anlegt.
Wer die Container-Option auswählt, entscheidet sich in dieser Version für den direkten Container-Arbeitsbereich. Das ist passend, wenn die dort eingerichteten Werkzeuge und Abhängigkeiten benötigt werden. Wenn stattdessen ein separater Worktree für parallele Änderungen entscheidend ist, steht die Dev-Container-Ausführung für dieselbe Sitzung nicht zur Verfügung.
Diese Unterscheidung hat unmittelbare Folgen für die Nutzung: Änderungen des Agenten erscheinen im eingebundenen Projektarbeitsbereich. Vor dem Start sollte deshalb klar sein, welcher Ordner geöffnet ist und welchen Zustand dieser Arbeitsbereich hat. Die Einschränkung ist in der Dokumentation sowohl zum Agents-Fenster als auch zu den unterstützten Agent-Harnesses festgehalten.
Die Container-Wahl ist vom Agent-Harness getrennt
VS Code unterscheidet zwischen dem Ausführungsort einer Sitzung und dem verwendeten Agent-Harness. Als Harnesses nennt die Dokumentation GitHub Copilot, Anthropic Claude und OpenAI Codex. Die Wahl eines Harnesses bestimmt, welcher Agent die Aufgabe bearbeitet. „Use Dev Container“ legt dagegen fest, wo dessen VS Code Agent Host läuft.
Damit ist der Dev Container kein eigener Agent und auch kein zusätzliches Modell. Er stellt die Umgebung für eine über das Agents-Fenster gestartete Sitzung bereit. Diese Trennung verhindert ein verbreitetes Missverständnis: Ein Wechsel des Harnesses ersetzt nicht die Container-Konfiguration, und die Container-Ausführung entscheidet nicht automatisch, welcher Agent genutzt wird.
Praktisch lässt sich dieselbe Projektumgebung dadurch als gemeinsame technische Grundlage für unterstützte Harnesses verstehen. Die konkrete Verfügbarkeit hängt dennoch von den jeweiligen Zugängen und Abonnements ab. GitHub bietet etwa einen kostenlosen Copilot-Tarif mit begrenzter Agent-Nutzung sowie mehrere kostenpflichtige Varianten an. Diese Tariffrage ist vom neuen Ausführungsort getrennt und ändert nichts an den Voraussetzungen des Dev Containers.
Was sich für bestehende Projekte konkret anbietet
Besonders naheliegend ist die neue Option bei Projekten, deren Dev-Container-Konfiguration bereits die maßgebliche Entwicklungsumgebung definiert. Dann muss für die Agent-Sitzung keine zweite lokale Werkzeuglandschaft gepflegt werden. Der Container wird zur gemeinsamen Referenz für manuelle Entwicklung und agentische Befehle.
Das bietet sich beispielsweise für Repositories an, die eine bestimmte Laufzeit, zusätzliche Systempakete oder projektgebundene Kommandozeilenwerkzeuge voraussetzen. Auch beim Wechsel zwischen mehreren Projekten hilft die klare Zuordnung: Jede Sitzung kann in der Umgebung des jeweiligen Projekts arbeiten, während das zentrale Agents-Fenster die Sitzungen arbeitsbereichsübergreifend sichtbar hält.
Weniger passend ist die Option, wenn das Projekt keine Dev-Container-Konfiguration besitzt oder die Aufgabe ausdrücklich in einem neu erzeugten Worktree isoliert werden soll. Ebenso bleibt eine lokal installierte Voraussetzung außerhalb des Containers für die Sitzung ohne Wirkung, sofern sie nicht in der Container-Umgebung verfügbar ist. Der Agent arbeitet bewusst mit dem Werkzeugbestand des Containers.
Die eigentliche Neuerung ist Umgebungstreue
VS Code 1.138 verbindet zwei bislang getrennte Ebenen enger miteinander: die zentrale Verwaltung von Agent-Sitzungen im lokalen Agents-Fenster und die projektspezifische Ausführung im Dev Container. Das sichtbare Fenster bleibt auf dem Rechner, der zuständige Agent Host läuft im Container und führt dort Dateiänderungen sowie Befehle aus.
Damit wird aus dem Dev Container eine direkt wählbare Laufzeitumgebung für Coding-Agenten. Der Nutzen ist besonders konkret, wenn ein Projekt seine Abhängigkeiten und Werkzeuge bereits im Container festgelegt hat. Die Sitzung arbeitet dann nicht nur am richtigen Code, sondern auch am richtigen technischen Ort. Docker, eine vorhandene Dev-Container-Konfiguration und die aktivierte Einstellung sind dafür notwendig; ein paralleler neuer Worktree ist in dieser Startart nicht möglich.