VS Code 1.109 kann Claude, Codex und Copilot gleichzeitig als Agenten ausführen. Nicht als Extensions, die eine API wrappen. Als vollwertige Agent-Laufzeitumgebungen mit eigenem Session-Management, paralleler Subagenten-Ausführung und Tool-Sandboxing. Das Januar-2026-Update verwandelt den weltweit meistgenutzten Code-Editor von einem Tool mit KI-Features in einen Orchestrierungs-Hub, in dem mehrere KI-Agenten parallel an der Codebasis arbeiten, jeweils in isolierten Kontexten mit eingeschränkten Berechtigungen.
Das ist relevant, weil der Engpass bei KI-gestützter Entwicklung längst nicht mehr die Modellfrage ist. Der Engpass ist die Koordination mehrerer Modelle mit unterschiedlichen Stärken über eine Codebasis, die jedes einzelne Kontextfenster sprengt. VS Code 1.109 ist Microsofts Antwort: Die IDE wird zum Betriebssystem für KI-Agenten.
Subagenten: Kontextisolierung, die funktioniert
Das wichtigste Feature in 1.109 sind Subagenten. Vor diesem Release teilten sich alle KI-Interaktionen in VS Code einen einzigen Gesprächskontext. Dependency recherchieren, API erkunden, Modul refactoren: Alles verbrauchte dasselbe Token-Budget. Kontextfenster liefen voll. Die Ergebnisse wurden schlechter.
Subagenten lösen das Problem, indem sie in komplett isolierten Kontextfenstern laufen. Der Hauptagent delegiert eine Aufgabe, der Subagent führt sie unabhängig aus, und nur das Endergebnis kehrt in den primären Kontext zurück. Die Zwischenschritte, Sackgassen und iterativen Verfeinerungen bleiben gekapselt.
Der praktische Effekt ist erheblich. Ein Subagent, der Testmuster in einem Projekt recherchiert, verbraucht kein einziges Token aus dem Kontextbudget, das der Hauptagent für die eigentliche Refactoring-Arbeit braucht. VS Code kann zudem mehrere Subagenten parallel ausführen und unabhängige Aufgaben auf gleichzeitige Ausführungsthreads verteilen.
Subagenten-Verhalten konfigurieren
Custom Agents steuern den Subagenten-Zugriff über Frontmatter-Attribute in .github/copilot-agents/-Prompt-Dateien:
---
name: TDD
tools: ['agent']
agents: ['Red', 'Green', 'Refactor']
---
Tests schreiben, dann implementieren, dann aufräumen.
Die agents-Property akzeptiert eine Liste spezifischer Agent-Namen, * für alle verfügbaren Agenten oder [] zum vollständigen Deaktivieren. Zwei weitere Properties steuern die Sichtbarkeit:
user-invokable: falseverbirgt den Agenten im Dropdown, sodass er nur als Subagent verfügbar istdisable-model-invocation: trueverhindert, dass andere Agenten diesen Agenten aufrufen
Dieses Berechtigungsmodell wird relevant, sobald mehr als ein Agent im Workspace aktiv ist. Ohne Einschränkungen könnte ein allgemeiner Agent einen Deployment-Agenten aufrufen, der wiederum einen Datenbankmigrationsagenten startet. Wer festlegt, welcher Agent welchen anderen aufrufen darf, verhindert kaskadierende Automatisierungen, die niemand angefordert hat.
Drei Ausführungsmodi: Lokal, Hintergrund, Cloud
VS Code 1.109 formalisiert drei Modi für die Agent-Ausführung mit jeweils unterschiedlichen Kompromissen:
Lokale Agenten laufen auf dem eigenen Rechner innerhalb von VS Code mit vollem Tool-Zugriff. Sie sehen den Workspace, das Terminal und alle Extensions. Optimal für interaktive Arbeit, bei der man den Agenten in Echtzeit steuern möchte.
Hintergrund-Agenten laufen über CLI auf dem lokalen Rechner, aber außerhalb der VS Code UI. Sie arbeiten in Git Worktrees, um Konflikte mit dem aktiven Workspace zu vermeiden. Ideal für klar definierte Aufgaben, die man losschickt und später prüft.
Cloud-Agenten laufen auf Remote-Infrastruktur und integrieren sich in GitHubs PR-Workflow. Sie haben keinen Zugriff auf VS Codes eingebaute Tools oder die lokale Laufzeitumgebung, erzeugen aber Pull Requests, die das Team asynchron reviewen kann.
Die entscheidende Design-Entscheidung: Man kann Arbeit zwischen diesen Modi mitten im Gespräch übergeben. Lokal anfangen, um das Problem zu erkunden, dann zu einem Hintergrund-Agenten für die Implementierung wechseln und schließlich an einen Cloud-Agenten für den PR übergeben. VS Code überträgt den vollständigen Gesprächsverlauf beim Wechsel.
Claude und Codex als vollwertige Agenten
Die auffälligste Neuerung in 1.109: Claude- und Codex-Agenten werden nicht in VS Codes bestehende Copilot-Abstraktion eingewickelt. Sie laufen über ihre jeweiligen nativen SDKs. Claude Agent nutzt Anthropics offizielles Harness mit denselben Prompts, Tools und derselben Architektur wie eigenständige Claude-Agent-Deployments.
Codex läuft lokal mit einem Copilot-Pro+-Abo. Claude Agent ist in der öffentlichen Preview. Beide werden über die einheitliche Agent-Sessions-Ansicht verwaltet. Man steuert alle Agenten von einer Oberfläche aus, unabhängig davon, welches Modell sie antreibt.
Das eröffnet eine interessante Dynamik: Codex für schnelle interaktive Aufgaben nutzen (es ist 25% schneller als sein Vorgänger) und Claude für komplexes autonomes Refactoring (mit 1M Token Kontextfenster). Dieselbe IDE, dasselbe Session-Management, verschiedene Modelle für verschiedene Aufgaben.
Agent Skills und Orchestrierungen
Agent Skills, die letztes Jahr in der Preview erschienen, sind in 1.109 jetzt allgemein verfügbar. Skills sind gebündelte Anweisungen, die Agenten domänenspezifisches Verhalten beibringen: Teststrategien, API-Design-Konventionen, Performance-Optimierungsmuster.
Sie funktionieren über den chatSkills-Contribution-Point, was bedeutet, dass Extension-Autoren Skills über den VS Code Marketplace verteilen können. Teams können interne Skills veröffentlichen, die ihre spezifischen Konventionen kodifizieren, und jeder Agent in jedem Entwickler-Workspace erbt sie.
Der praktische Nutzen ist Konsistenz. Wenn zehn Entwickler im Team jeweils Agent-Modus mit unterschiedlichen Prompting-Gewohnheiten verwenden, entstehen zehn verschiedene Coding-Stile. Skills standardisieren den Output. Man konfiguriert sie über chat.agentSkillsLocations oder nutzt den /init-Befehl, der die Projektstruktur analysiert und automatisch workspace-spezifische Anweisungen generiert.
Das Conductor-Pattern
Community-Projekte wie Copilot Orchestra zeigen, was mit Subagenten-Orchestrierung möglich wird. Ein “Conductor”-Agent teilt eine Aufgabe in Phasen (Planung, Implementierung, Code-Review), delegiert jede Phase an einen spezialisierten Subagenten und synthetisiert die Ergebnisse. Jeder Subagent nutzt die Tools und Anweisungen, die seiner Rolle entsprechen.
Dieses Pattern entspricht im Kern der Architektur, die Anthropic zum Bau eines C-Compilers mit 16 parallelen Claude-Agenten eingesetzt hat. Nur läuft es innerhalb der IDE statt in einer eigenen Docker-Orchestrierung.
Terminal-Sandboxing und Vertrauen
Mehrere KI-Agenten im Editor auszuführen erzeugt eine echte Angriffsfläche. Ein Agent mit Terminal-Zugriff kann beliebige Befehle ausführen. Zwei Agenten, die sich einen Workspace teilen, können gegenseitig ihre Änderungen überschreiben. Ein bösartiger MCP-Server könnte einen Agenten anweisen, Quellcode nach außen zu übertragen.
VS Code 1.109 adressiert das mit Terminal-Sandboxing (derzeit experimentell auf macOS und Linux). Aktiviert über chat.tools.terminal.sandbox.enabled, laufen agent-ausgeführte Befehle in eingeschränkten Umgebungen mit konfigurierbaren Datei- und Netzwerk-Zugriffsrichtlinien. Ein Agent kann Quellcode lesen, aber nicht die SSH-Keys anfassen. Er kann Tests ausführen, aber keine Daten an externe Endpunkte senden.
Auto-Approval-Regeln (chat.tools.terminal.enableAutoApprove) ergänzen das Sandboxing: Sichere Befehle wie dir, docker ps und npm test werden ohne Bestätigungsdialog ausgeführt, während alles außerhalb der Allowlist explizite Genehmigung erfordert. Weniger Reibung bei Routineoperationen, mehr Kontrolle bei riskanten.
Copilot Memory
Agenten in 1.109 erhalten persistenten Speicher über Sessions hinweg via Copilot Memory (aktivierbar mit github.copilot.chat.copilotMemory.enabled). Der Agent merkt sich Präferenzen wie “Vor Änderungen immer Rückfragen stellen” oder “Funktionale Patterns statt klassenbasierter Komponenten bevorzugen.”
Das klingt nach einem kleinen Feature, löst aber eines der größten Ärgernisse bei KI-Coding-Agenten: dieselben Anweisungen in jeder Session wiederholen. Kombiniert man Memory mit Skills und Custom-Agent-Definitionen, bekommt jeder Entwickler ein KI-Team, das Vorlieben, Teamkonventionen und Projektarchitektur vom ersten Prompt an kennt.
Was das für Entwicklungsteams bedeutet
VS Code 1.109 ist nicht einfach ein weiteres Feature-Release. Es ist ein Plattformwechsel. Microsoft positioniert den Editor als Laufzeitumgebung für Multi-Agent-Entwicklung, ähnlich wie Windows vor dreißig Jahren als Laufzeitumgebung für Desktop-Anwendungen positioniert wurde.
Die praktischen Auswirkungen für Teams, die KI-Agenten einsetzen:
Vendor Lock-in sinkt. Wenn Claude, Codex und Copilot alle innerhalb derselben Session-Management-Schicht laufen, wird der Modellwechsel zum Dropdown-Klick. Man ist nicht an das Ökosystem eines einzelnen Anbieters gebunden.
Agent-Governance wird einfacher. Subagenten-Einschränkungen, Terminal-Sandboxing und Auto-Approval-Regeln geben Teams die Kontrollen, die sie brauchen, um Agenten einzusetzen, ohne den Überblick zu verlieren. Das ist besonders relevant für Organisationen, die unter dem EU AI Act arbeiten, wo Rückverfolgbarkeitsanforderungen auch für KI-gestützte Entwicklungsprozesse gelten.
Kontextmanagement wird explizit. Das Subagenten-Modell zwingt dazu, darüber nachzudenken, welche Aufgaben gemeinsamen Kontext brauchen und welche isoliert sein sollten. Das ist dasselbe architektonische Denken, das verteilte Systeme funktionieren lässt: explizite Grenzen, klare Verträge, unabhängige Fehlerdomänen.
Die größte Frage, die 1.109 aufwirft, betrifft nicht VS Code selbst. Es geht darum, was passiert, wenn die IDE zur Orchestrierungsschicht für die gesamte KI-Agent-Flotte eines Teams wird. Wenn Code-Review-Agent, Testing-Agent, Dokumentations-Agent und Deployment-Agent alle innerhalb von VS Code mit persistentem Speicher und geteilten Skills laufen, ist der Editor kein Texteditor mehr. Er ist ein Agent-Betriebssystem.
Häufig gestellte Fragen
Was sind Subagenten in VS Code 1.109?
Subagenten sind kontextisolierte KI-Agenten, die unabhängig von der Haupt-Chat-Session laufen. Der Hauptagent delegiert Aufgaben an Subagenten, diese arbeiten in eigenen Kontextfenstern, und nur das Endergebnis kehrt in den primären Kontext zurück. Das verhindert Kontextfenster-Überläufe und ermöglicht parallele Ausführung unabhängiger Aufgaben.
Kann man Claude und Codex in VS Code nutzen?
Ja. VS Code 1.109 unterstützt Claude Agent (in öffentlicher Preview) und Codex-Agenten neben GitHub Copilot. Claude nutzt Anthropics offizielles Agent SDK, während Codex lokal oder in der Cloud läuft. Beide erfordern ein Copilot-Pro+- oder Enterprise-Abo. Alle Agenten werden über die einheitliche Agent-Sessions-Ansicht verwaltet.
Was ist Terminal-Sandboxing im VS Code Agent-Modus?
Terminal-Sandboxing beschränkt, welche Befehle KI-Agenten ausführen können. Aktiviert über die Einstellung chat.tools.terminal.sandbox.enabled, lassen sich Datei- und Netzwerk-Zugriffsrichtlinien für agent-ausgeführte Terminal-Befehle konfigurieren. Derzeit experimentell und nur auf macOS und Linux verfügbar.
Was sind VS Code Agent Skills?
Agent Skills sind gebündelte Anweisungspakete, die KI-Agenten domänenspezifisches Verhalten beibringen, etwa Teststrategien, API-Design-Konventionen oder Performance-Optimierungsmuster. Sie sind seit VS Code 1.109 allgemein verfügbar und können über Extensions mit dem chatSkills-Contribution-Point verteilt werden.
Wie funktioniert Copilot Memory in VS Code 1.109?
Copilot Memory ermöglicht KI-Agenten, relevanten Kontext und Präferenzen über Sessions hinweg zu speichern. Aktivierbar mit github.copilot.chat.copilotMemory.enabled. Der Agent merkt sich Coding-Stil-Präferenzen, Projektkonventionen und Interaktionsmuster, sodass Anweisungen nicht in jeder neuen Session wiederholt werden müssen.