VS Code 1.132: Agenten, Sprache und Kontrolle

VS Code 1.132 macht Agenten zur Arbeitsumgebung

VS Code 1.132 ist am 5. August 2026 als stabile Version erschienen. Das Update wirkt auf den ersten Blick wie eine Sammlung einzelner Komfortfunktionen: Kommentare im integrierten Browser, mehrsprachige Diktation, Side-Chats und Markdown-Diffs. Zusammen ergeben diese Bausteine jedoch ein klares Bild. Microsoft behandelt KI-Agenten nicht mehr als zusätzliches Chatfenster, sondern als eigene Arbeitsebene, die Code, Browser, Terminal, Sprache und Reviews verbindet.

Die offizielle Release Note zu Visual Studio Code 1.132 nennt vier sichtbare Schwerpunkte. Entwickler können Agenten Rückmeldung an konkreten Webseitenelementen geben, während einer laufenden Aufgabe Nebenfragen stellen, Sprache lokal in Text umwandeln und Änderungen an Markdown-Dokumenten in einer gerenderten Ansicht prüfen. Das klingt nach kleinen Abkürzungen. Praktisch verändert es, wie viele Kontextwechsel ein Team während einer agentengestützten Aufgabe bewältigen muss.

Wichtig ist die Trennung der Reifegrade. Die Ausgabe selbst ist Stable, doch der Agent Host wird progressiv ausgerollt. Markdown-Diffs im hybriden Editor sind ausdrücklich experimentell, und eine neue Prioritätssteuerung für Custom Editors steht unter Proposed APIs. Wer das Update bewertet, darf diese Ebenen nicht vermischen. Eine stabile Versionsnummer bedeutet nicht, dass jede beschriebene Funktion bereits für jeden Nutzer und jede Unternehmensrichtlinie gleich verfügbar ist.

Für den Arbeitsalltag lautet die zentrale Frage deshalb nicht, ob die Liste modern klingt. Entscheidend ist, ob Ihre Teams Agenten nachvollziehbar einsetzen können, ohne laufende Aufgaben, Nebenfragen und Reviews in einem einzigen Chatverlauf zu vermengen. VS Code 1.132 liefert dafür neue Oberflächen und Prozesse. Die Verantwortung für Grenzen, Freigaben und reproduzierbare Ergebnisse bleibt dennoch bei der Organisation.

Agent Host und Agents Window bündeln mehrere Sitzungen

Der Agent Host führt Agent-Harnesses in einem eigenen Prozess aus und soll dieselbe Agent-Sitzung über mehrere VS-Code-Fenster zugänglich machen. Microsoft nennt in der Release Note drei Harnesses ausdrücklich: Copilot, Claude und Codex. Das ist mehr als eine Auswahl im Dropdown. Die Architektur trennt den Agenten stärker vom einzelnen Editorfenster und schafft einen Ort, an dem unterschiedliche Agent-Laufzeiten nach einem gemeinsamen Protokoll angebunden werden können.

Das Agents Window ergänzt diese Ebene um eine spezielle Arbeitsfläche für mehrere Sitzungen. Status-Pills zeigen Änderungen, Vorschauen, Subagenten und Browseraktivität der ausgewählten Session. Damit wird sichtbar, woran ein Agent gerade arbeitet und welche Nebenaktivitäten dazugehören. Für Teams, die bereits GitHub Copilot mit externen Werkzeugen verbinden, ist diese Übersicht besonders relevant: Je mehr Systeme ein Agent berührt, desto wichtiger wird die Trennung einzelner Aufgaben und ihrer Resultate.

Mit /btw kommt ein zweiter Mechanismus hinzu. Eine Nebenfrage teilt Kontext und Prompt-Cache der Hauptunterhaltung, unterbricht aber den laufenden Agent-Turn nicht. Das passt zu realer Entwicklungsarbeit: Während ein Agent Dateien ändert, möchte ein Entwickler vielleicht wissen, warum eine Bibliothek gewählt wurde oder welche Tests betroffen sind. Bisher konnte eine solche Frage den Hauptfluss überladen. Der Side-Chat macht aus der Nachfrage einen separaten, aber kontextgebundenen Pfad.

Die offizielle Dokumentation zum Agent Host bleibt deshalb Pflichtlektüre vor einem breiten Rollout. Ein eigener Prozess und mehrere Sitzungen verbessern die Bedienung, lösen aber keine Governance-Frage automatisch. Teams müssen weiterhin dokumentieren, welcher Harness verwendet wird, welche Werkzeuge er aufrufen darf und wie Änderungen überprüft werden. Komfort ersetzt weder Berechtigungen noch einen nachvollziehbaren Review.

Diktation bleibt lokal und versteht den Terminalkontext

Die Diktation in VS Code 1.132 nutzt standardmäßig multilingual Nemotron 3.5 als On-Device-Modell. Audio bleibt laut Release Note auf dem Gerät. Die Sprache folgt entweder der Einstellung agents.voice.language, der System- beziehungsweise Browser-Locale oder wird automatisch erkannt. Das ist für mehrsprachige Teams praktischer als ein fester Sprachmodus und reduziert zugleich die Notwendigkeit, Sprachdaten für die Transkription an einen entfernten Dienst zu senden.

Die integrierte Diktation arbeitet in drei Kontexten: Chat-Eingaben, Editoren und Terminals. Beim ersten Einsatz führt ein Onboarding durch Mikrofonwahl, Live-Wellenform und Einstellungen. Projektspezifische Anweisungen können aus ~/.copilot/dictation.md und .github/dictation.md einfließen, sofern der Workspace vertrauenswürdig ist. Damit lässt sich die Transkription an Fachbegriffe und Formatregeln anpassen, ohne das Grundmodell selbst zu verändern.

Im Terminal kommt eine shell-bewusste Bereinigung hinzu. Die Release Note zeigt das Beispiel, dass die gesprochenen Wörter für einen Git-Commit in syntaktisch passenden Befehlstext übersetzt werden. Das ist nützlich, aber kein Sicherheitsfilter. Eine korrekt formatierte Shell-Zeile kann weiterhin falsch oder gefährlich sein. Vor dem Ausführen muss deshalb dieselbe Prüfung gelten wie bei manuell eingegebenen oder von einem Agenten vorgeschlagenen Kommandos.

Auch lokale Verarbeitung beseitigt nicht alle Risiken. Diktationsdateien im Home-Verzeichnis oder Repository werden Teil des Arbeitskontexts und sollten wie andere Entwicklungsrichtlinien versioniert, geprüft und möglichst knapp gehalten werden. In gemeinsam genutzten Projekten braucht es zudem klare Zuständigkeiten für .github/dictation.md. Sonst kann eine gut gemeinte Sprachregel unbeabsichtigt technische Begriffe verändern oder Formatierungen erzwingen, die nicht zum Projekt passen.

Dieses Bild wurde komplett mit KI generiert

Providerhiggsfield

Modellseedream_v4_5

PromptIn side profile at a quiet developer workstation, a person speaks toward a plain compact matte-black microphone while two generic bezel-free monitors remain softly out of focus behind them. The blurred screens contain exactly three broad unlabeled color regions suggesting chat, editor, and terminal activity, with no characters, icons, product marks, captions, labels, interface details, or hardware badges. Photorealistic style image. Mood: precise, calm, and privacy-conscious. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Browser-Kommentare und Markdown-Diffs verkürzen Reviews

Im integrierten Browser lassen sich nun einzelne Seitenelemente auswählen und mit Feedback für den Agenten versehen. Mehrere Elemente können vor dem Senden jeweils einen Kommentar erhalten. Für Frontend-Aufgaben ist das präziser als eine allgemeine Anweisung wie „der obere Bereich wirkt falsch“. Der Agent bekommt einen Bezug zwischen sichtbarem Objekt und Rückmeldung. Das reduziert Missverständnisse, sofern die Auswahl und der Kommentar selbst eindeutig bleiben.

Diese Funktion ergänzt den bereits sichtbaren Trend, Entwicklungswerkzeuge enger mit isolierten Laufzeitumgebungen zu verbinden. Beim WASI-Support in VS Code steht die kontrollierte Ausführung von Modulen im Vordergrund; beim Browser-Kommentar geht es um kontrollierten visuellen Kontext. In beiden Fällen soll der Editor mehr Informationen bereitstellen, ohne dass Entwickler zwischen zahlreichen getrennten Werkzeugen wechseln müssen.

Für Dokumentation bringt der hybride Markdown-Editor nun Diffs. Die geänderte Fassung bleibt editierbar, während Markierungen hinzugefügte, veränderte und gelöschte Inhalte anzeigen. Das kann Reviews von README-Dateien, Architekturentscheidungen oder Runbooks deutlich angenehmer machen, weil Inhalt und Darstellung gleichzeitig sichtbar bleiben. Die Funktion ist allerdings als Experimental gekennzeichnet. Sie gehört deshalb zunächst in einen begrenzten Test und nicht ungeprüft in einen verbindlichen Freigabeprozess.

Visuelles Feedback darf außerdem nicht mit fachlicher Korrektheit verwechselt werden. Ein Agent kann ein markiertes Element sauber verschieben und trotzdem Barrierefreiheit, responsive Zustände oder Datenbindung beschädigen. Ebenso kann ein Markdown-Diff plausibel aussehen, während ein entscheidender Satz inhaltlich falsch ist. Die neuen Ansichten verkürzen die Schleife zwischen Hinweis und Änderung. Sie ersetzen keine Tests, keine fachliche Abnahme und keine Prüfung der finalen Datei.

Mehr Freiheit bringt neue Governance-Kosten

Die auffälligste administrative Änderung steht nicht in der Highlight-Liste. Microsoft entfernt die Richtlinie ChatAgentHostEnabled. Administratoren können den Agent Host damit nicht mehr zentral über diese Policy deaktivieren. Entwickler können weiterhin über chat.agentHost.enabled steuern, ob Agenten im separaten Host-Prozess laufen. Diese Verschiebung ist relevant, weil eine lokale Einstellung organisatorisch etwas anderes ist als eine zentral durchgesetzte Unternehmensrichtlinie.

Unternehmen sollten daraus weder Panik noch Gleichgültigkeit ableiten. Die entfernte Policy sagt nicht, dass sämtliche Berechtigungen verschwinden. Sie zeigt aber, dass Agent-Governance nicht an einem einzelnen Produktschalter hängen darf. Identität, Erweiterungsfreigaben, Netzwerkzugriff, Repository-Regeln, Secret-Verwaltung und Reviewpflichten müssen unabhängig davon funktionieren, ob der Agent Host aktiv ist. Eine zentrale Deaktivierung war ohnehin nur eine grobe Grenze.

Das Muster ähnelt der Governance für Agenten-Automation in GitHub Issues: Sobald Assistenten nicht nur antworten, sondern Arbeitsschritte koordinieren, braucht jede Aktion einen klaren Verantwortungsbereich. Status-Pills und separate Sessions erhöhen Sichtbarkeit, doch Sichtbarkeit ist noch keine Autorisierung. Ein Team muss festlegen, welche Agenten lesen, schreiben, Befehle ausführen oder externe Systeme ansprechen dürfen.

Für regulierte Umgebungen empfiehlt sich deshalb ein eigener Prüfpunkt für VS Code 1.132. Erfassen Sie verfügbare Harnesses, aktive Erweiterungen, Workspace-Trust-Regeln und lokale Einstellungen. Prüfen Sie außerdem, ob bestehende Richtlinien ausdrücklich auf die entfernte Policy angewiesen waren. Wo zentrale Kontrolle entfällt, muss eine gleichwertige technische oder organisatorische Leitplanke dokumentiert sein. Ein stiller Verlust an Durchsetzung wäre riskanter als jede sichtbare neue Agentenfunktion.

So testen Sie VS Code 1.132 kontrolliert

Beginnen Sie mit einer abgegrenzten Referenzaufgabe, nicht mit dem gesamten Repository. Ein geeigneter Pilot umfasst eine kleine Codeänderung, eine Browseransicht und eine Markdown-Dokumentation. So lassen sich Agent Host, Elementkommentare und der experimentelle Diff getrennt beobachten. Notieren Sie dabei Version, verwendeten Harness, aktivierte Einstellungen und ausgeführte Werkzeuge. Nur ein reproduzierbarer Ablauf zeigt, ob der neue Komfort tatsächlich Zeit spart.

Testen Sie Side-Chats anschließend bewusst gegen den Hauptfluss. Stellen Sie während einer laufenden Aufgabe eine Kontextfrage mit /btw und prüfen Sie, ob Antwort und Hauptarbeit sauber getrennt bleiben. Öffnen Sie dieselbe Session in einem zweiten Fenster, sofern der Agent Host für Ihr Konto verfügbar ist. Da der Rollout progressiv erfolgt, ist eine fehlende Option nicht automatisch ein Konfigurationsfehler. Dokumentieren Sie den beobachteten Zustand statt Verfügbarkeit zu unterstellen.

Für die Diktation sollten Sie mindestens einen Editor-, Chat- und Terminalfall verwenden. Prüfen Sie Fachbegriffe, Zeichensetzung und Shellsyntax, führen Sie Befehle aber nicht ungeprüft aus. Testen Sie projektspezifische Anweisungen zunächst in einem unkritischen Workspace. Beim Markdown-Diff vergleichen Sie die gerenderte Ansicht zusätzlich mit dem Textdiff und dem finalen Git-Diff. Damit bleibt die experimentelle Oberfläche eine Hilfe und wird nicht zur einzigen Wahrheit.

VS Code 1.132 ist damit kein revolutionärer Sprung, aber ein wichtiges Betriebsupdate für agentengestützte Entwicklung. Microsoft verbindet mehrere bislang getrennte Interaktionen zu einem zusammenhängenden Arbeitsraum. Der Nutzen entsteht, wenn Teams Kontextwechsel reduzieren und Ergebnisse besser nachvollziehen können. Die Grenze bleibt ebenso klar: Progressive und experimentelle Funktionen brauchen Pilotierung, und neue Agentenoberflächen sind nur dann produktiv, wenn Berechtigungen, Reviews und Rückwege bereits feststehen.