VS Code 1.144 führt die Programmiersitzung über den Laptopdeckel hinaus

Sie beginnen eine Programmieraufgabe am Schreibtisch, prüfen sie von einem anderen Gerät und kehren später zur Diff-Prüfung zurück. Nützlich ist dabei eine fortlaufende Aufgabe mit denselben Anweisungen und sichtbaren Entscheidungen. Nach jedem Gerätewechsel ein Gespräch rekonstruieren zu müssen, ist zusätzliche Entwicklungsarbeit.

VS Code 1.144 erschien am 28. Oktober 2026 als stabile Version. Die Versionshinweise verbinden fortgesetzte Agentensitzungen und Fernverwaltung mit Funktionen, die eigene Kennzeichnungen als Preview oder Experimental tragen. Cloudsitzungen laufen auf GitHub-Infrastruktur und können deshalb weiterarbeiten, während der Entwicklungslaptop offline ist. Offizielle Versionshinweise.

Dieser Leitfaden erklärt den Unterschied zwischen Client und Ausführungsort, den Beitrag des Agent Host Protocol und die Bewertung einer fortlaufenden Sitzung durch eine echte Codeprüfungsübergabe.

Offizieller Screenshot der Remote Environments von Visual Studio Code 1.144. Used with permission from Microsoft. Bildquelle · Lizenz und Bildhinweise.

Ein Fenster zu schließen und einen Worker zu stoppen sind verschiedene Ereignisse

Eine Programmieroberfläche zeigt Nachrichten, Dateien und Freigabeanfragen. Der ausführende Prozess kann anderswo liegen. Sind diese Rollen getrennt, muss das Schließen der Oberfläche die Aufgabe nicht beenden, sofern Host und Umgebung verfügbar bleiben.

Microsofts Universe-Überblick vom 28. Oktober beschreibt den Agent Host als unabhängigen Prozess für Sitzungen, Harnesses, Modelle, Dateien und Terminals. Demnach hat das Agent Host Protocol Version 1.0 erreicht und verbindet Clients mit fortlaufendem Sitzungszustand. Diese Architekturunterscheidung hilft zu bewerten, was „weiterarbeiten“ tatsächlich bedeutet.

Ein lokaler Host hängt weiterhin vom lokalen Rechner ab. Ein Remotehost hängt von seinem Rechner und der Verbindungseinrichtung ab. Eine Cloudsitzung hat eine gesondert gehostete Umgebung. Wählen Sie den Ausführungsort danach, was verfügbar bleiben muss, wenn der Client verschwindet.

Der Client ähnelt einem Leitstandfenster. Ein anderes Fenster kann dieselbe Arbeit zeigen, verschiebt aber nicht die Maschinen darunter. Ein Telefon, das eine Sitzung anzeigt, macht aus einem schlafenden lokalen Computer keinen ständig verfügbaren Server.

Unsere Einschätzung: Beständigkeit wird nützlich, wenn die Identität der Aufgabe mit ihrer Ausführung erhalten bleibt. Die fortgesetzte Sitzung sollte Repository, erzeugte Änderungen und ausstehende Entscheidungen deutlich zeigen. Einen Prozess lediglich am Leben zu halten ist eine kleinere Leistung.

Eigene Erklärung der Zuständigkeit von Client und Host auf Grundlage des VS-Code-Universe-Überblicks. Dies ist ein vereinfachtes Planungsmodell, keine Netzwerktopologie.

AHP synchronisiert die von den Oberflächen betrachtete Sitzung

Die am 2. November geprüfte offizielle Agent-Host-Protocol-Seite beschreibt AHP als bidirektionales, zustandsbasiertes Darstellungsprotokoll. Clients arbeiten mit gemeinsamem Sitzungszustand; der Host verteilt Aktionen und entscheidet Konflikte. Beim Wiederverbinden können verpasste Aktionen oder ein aktueller Snapshot die Oberfläche aufholen lassen.

Das zählt, weil eine Agentensitzung mehr als ein Transkript enthält. Dazu können eine wartende Freigabe, ein laufendes Terminal oder eine geänderte Datei gehören. Zeigen zwei Oberflächen unterschiedliche Versionen dieser Fakten, kann die bedienende Person falsch entscheiden, selbst bei guter Codegenerierung.

Die Wiederverbindungsbeispiele des Protokolls zeigen den Abgleich ausstehender Clientaktionen mit dem Hostzustand. Praktisch heißt das: Eine Wiederverbindung sollte die aktuelle Aufgabensituation einschließlich des Schicksals einer früheren Anfrage herstellen. Man sollte nicht raten müssen, ob eine Freigabe vor dem Netzausfall ankam.

Ein gemeinsames Protokoll schafft auch eine Grenze für Clientinteroperabilität. Ein Client muss die angezeigten Zustände und Aktionen verstehen. Die Existenz eines Protokolls bedeutet nicht, dass bereits jedes Werkzeug mit jedem Anbieter verbunden werden kann oder jede Funktion identisch anbietet.

Prüfen Sie beim Oberflächenvergleich die wichtigen Entscheidungen Ihres Ablaufs. Zeigt der alternative Client eine ausstehende Berechtigungsanfrage? Erkennt er geänderte Dateien und Aufgabenstatus? Erhält die Rückkehr zum Editor dieselbe Aufgabe, statt ein zweites Gespräch zu starten?

Stabile Version und Vorschaufunktion sind getrennte Kennzeichnungen

Die VS-Code-Seite zu 1.144 bezeichnet die Version als Stable, während Cloud Automations, Bildgenerierung und Copilot-Connectors Preview bleiben; Computerbedienung und Working-Set-Funktionen sind Experimental. Cloudsitzungen erfordern einen bezahlten Copilot-Tarif und unterliegen Organisationsrichtlinien. Versions- und Funktionsstatus, 28. Oktober, geprüft am 2. November.

Das ist bei einem erweiterbaren Editor üblich: Eine stabile Anwendung kann einzelne Funktionen verschiedener Reifegrade enthalten. Die richtige Einführungsentscheidung betrifft Funktion und Ablauf statt allein die Versionsnummer.

Die Tabelle ist ein Betriebsvergleich, kein Versprechen identischen Verhaltens. Anforderungen der jeweiligen Erweiterung, des Modells und Harnesses bleiben wichtig. Prüfen Sie die von Ihrem Team beabsichtigte Kombination.

Wählen Sie für eine experimentelle Fähigkeit eine gesonderte, umkehrbare Übung. Beginnen Sie für die Kontinuitätsbewertung mit dem kleinsten Ablauf, der die Übergabe zeigt. Mehrere neue Funktionen gleichzeitig erschweren die Zuordnung unerwarteter Ergebnisse.

Drei beispielhafte Aufgaben zeigen den Nutzen von Kontinuität

Ein Entwickler kann eine begrenzte Korrektur übergeben und später prüfen

Stellen Sie sich einen Entwickler vor, der eine Cloudsitzung mit der Korrektur eines fehlschlagenden Parsertests beauftragt. Die Anweisung nennt Fehler, betroffenes Verhalten und erwartete Prüfung. Danach betrachtet er den Fortschritt über einen anderen unterstützten Client und kehrt zur Prüfung in den Editor zurück.

Die Abnahme sollte wie bei jeder Änderung aussehen: Die Korrektur behebt das Verhalten, relevante Prüfungen bestehen und der Diff ist angemessen. Dass die Arbeit bei geschlossenem Laptop weiterläuft, verändert ihren möglichen Zeitpunkt. Es belegt keine Merge-Reife.

Bitten Sie die Sitzung, für die Übergabe den genauen Testbefehl und dessen Ergebnis festzuhalten. „Tests bestanden“ ist schwerer zu bewerten als eine benannte Prüfung zu einer bestimmten Revision. Die prüfende Person braucht genügend Belege, ohne das ganze Gespräch rekonstruieren zu müssen.

Blockiert eine Freigabe oder ein fehlender Dienst die Aufgabe, sollte die Sitzung das zeigen. Eine aktive, aber nicht fortschreitende Aufgabe ist etwas anderes als nützliche Arbeit. Sichtbarkeit hilft bei der Entscheidung, einzugreifen, den Umfang zu ändern oder die Aufgabe warten zu lassen.

Ein Maintainer kann getrennte Probleme untersuchen, ohne Dateien zu vermischen

Ein beispielhafter Maintainer könnte eine Sitzung einen Fehler reproduzieren und eine andere Dokumentation untersuchen lassen. Bei klaren Grenzen nutzt das Wartezeit sinnvoll. Zugleich muss jedes Ergebnis beim eigenen Arbeitsbereich und Prüfkontext bleiben.

Definieren Sie Zuständigkeit vor dem Start. Benennen Sie Dateien oder Teilsystem, Branch oder Arbeitsbereich und erwartetes Ergebnis jeder Sitzung. Berühren zwei Aufgaben denselben Vertrag, legen Sie vor Anwendung beider Änderungen fest, wie die Erkenntnisse zusammengeführt werden.

Prüfen Sie ein Ergebnis gegen einen bekannten Repositoryzustand. Sonst kann ein bestandener Test von ungeprüften Änderungen einer anderen Sitzung abhängen. Eine Arbeitsbereichsgrenze macht den Ursprung eines positiven Ergebnisses leichter feststellbar.

Der Nutzen ist eine klarere Prüfwarteschlange, nicht bloß mehr gleichzeitige Agenten. Zwei sauber begrenzte Untersuchungen können Unsicherheit verringern; mehrere überlappende Änderungen können sie erhöhen. Die Agents-Oberfläche hilft, wenn der Maintainer erkennt, welche Situation entsteht.

Ein Team kann eine wiederkehrende Cloudaufgabe vor dem Zeitplan prüfen

Als beispielhaften Automationspilot nehmen wir eine regelmäßige Prüfung auf problematische Dokumentationslinks. Beginnen Sie mit einem nur lesenden Bericht und einem bestimmten Ergebnis. Lassen Sie es vor einer Erweiterung auf Änderungen menschlich prüfen.

Der Preview-Status von Cloud Automations zählt, weil wiederkehrende Arbeit eine weitere Betriebsverantwortung schafft. Ein einmal akzeptabler Lauf kann vor regelmäßiger Ausführung noch Ratenkontrollen, Verantwortliche und klare Fehlerreaktionen benötigen. Prüfen Sie das getrennt von der Qualität der Sprachausgabe.

Das Team sollte wissen, wo jeder Lauf Repositoryrevision, Befunde und externe Anfragen festhält. Kann er nicht abschließen, sollte der Datensatz offene Punkte nennen. Wiederkehrende Arbeit wird nützlich, wenn ihr Verantwortlicher eine unveränderte Situation von einer fehlgeschlagenen Prüfung unterscheiden kann.

Beginnen Sie mit einem Repository und bescheidenem Umfang. Erweitern Sie erst nach normalen Läufen, einem absichtlich blockierten Lauf und einer Ergebnisprüfung. Das sind vorgeschlagene Pilotschritte, keine Behauptungen über praktische Tests der Veröffentlichung.

Nicht committete Arbeit braucht eine ausdrückliche Übergabe

Die Versionshinweise zu 1.144 sagen, dass Cloudsitzungen einen separaten Arbeitsbereich verwenden und lokale nicht committete Änderungen nicht automatisch kopieren. Im Chat- oder Agents-Fenster kann man Cloud wählen, ein GitHub-Repository auswählen, nachfassen, Freigaben beantworten und Änderungen prüfen; bestehende Sitzungen lassen sich aus der Liste wieder öffnen. Cloudsitzungsanleitung.

Der separate Arbeitsbereich ist wichtig für alle mit einem lebhaften Checkout. Eine lokale Datei kann für die Aufgabe wesentlich sein, obwohl sie im für die Cloudsitzung sichtbaren Repositorystand fehlt. Bestimmen Sie vor der Übergabe die Quellrevision und den autorisierten Weg für Zusatzmaterial.

Verwechseln Sie einen Oberflächenwechsel nicht mit Dateitransfer. Dasselbe Gespräch fortzusetzen beweist nicht, dass alle lokalen Dateien oder Dienste mitgewandert sind. Eine Sitzung kann ihre Absicht behalten und trotzdem ausdrücklichen Zugriff auf das Ausführungsmaterial brauchen.

Fügen Sie einem beispielhaften Fehlerbericht die fehlerauslösende Eingabe in genehmigter, reproduzierbarer Form bei. Sagen Sie, ob der Agent committete Fixtures oder neu bereitgestelltes Material nutzen soll. Das gibt ihm einen konkreten Start und verhindert lange Untersuchungen eines Zustands, der das Problem nie enthielt.

Die Endprüfung sollte dieselbe Grenze rückwärts kontrollieren. Bestimmen Sie, wo Änderungen liegen und wie sie in den Arbeitsbranch gelangen. Erhalten Sie aktive lokale Änderungen bei Prüfung und Anwendung. Ein Remote-Arbeitsbereich darf seinen Nutzen nicht auf Kosten unklarer lokaler Arbeit erzielen.

Eigener Abnahmeablauf für eine fortlaufende Programmieraufgabe. Er verbindet die dokumentierte Cloud-Arbeitsbereichsgrenze mit normaler technischer Prüfung und berichtet kein unabhängiges Testergebnis.

Ein zehnminütiger Rundgang beweist weniger als eine vollständige Aufgabe

Die sichtbaren Teile der Kontinuität sind leicht zu bewerten: Eine Sitzung erscheint, ein Client verbindet sich wieder, eine Nachricht trifft ein. Diese Prüfungen helfen, doch das Ziel ist eine abgeschlossene Arbeit, deren Zustand die Übergabe übersteht.

Wählen Sie eine kleine Aufgabe mit prüfbarem Ergebnis. Eine Testfixture, Dokumentationskorrektur oder isolierte Verhaltenskorrektur eignet sich bei offensichtlicher Repositoryprüfung. Sie sollte aussagekräftig genug für Arbeitsbereichszustand und Berechtigungen sein, ohne den ersten Versuch unnötig auszuweiten.

1. Aktualisieren und prüfen Sie die installierte Version. Verwenden Sie VS Codes Aktualisierungssuche und bestätigen Sie die Version. Lesen Sie funktionsspezifische Kennzeichnungen in den offiziellen Hinweisen.
2. Wählen Sie eine autorisierte Ausführungsumgebung. Bestätigen Sie Repositoryzugriff, Tarifberechtigung und Organisationsrichtlinie. Entscheiden Sie zwischen lokalem, entferntem und Cloudhost.
3. Dokumentieren Sie den Ausgangszustand. Notieren Sie Repository und Revision. Erhalten Sie lokale Änderungen und bestimmen Sie benötigte Eingaben des gewählten Arbeitsbereichs.
4. Geben Sie eine begrenzte Anweisung. Benennen Sie Verhalten, Umfang und Prüfbefehl. Definieren Sie das zu prüfende Ergebnis.
5. Erproben Sie die Übergabe. Verlassen Sie den Client und verbinden Sie sich über eine verfügbare unterstützte Oberfläche wieder. Prüfen Sie Status, ausstehende Freigaben und neue Arbeit derselben Sitzung.
6. Kehren Sie zum Code zurück. Prüfen Sie Diff und Verifikationsbelege. Bestätigen Sie die Gültigkeit der Prüfungen für die geprüfte Revision.
7. Dokumentieren Sie Ergebnis und verbleibende Grenzen. Trennen Sie erfolgreiche Wiederverbindung, abgeschlossene Aufgabe und akzeptierte Änderung. Es sind verwandte Meilensteine mit unterschiedlichen Belegen.

Diagnostizieren Sie bei einem Fehlschlag die gescheiterte Grenze. Eine fehlende Fixture erfordert Arbeitsbereichsreparatur; ein blockierter Werkzeugaufruf eine Berechtigungsentscheidung; ein fehlender Host eine Umgebungsentscheidung. Derselbe Prompt behebt selten ein Problem außerhalb des Prompts.

Halten Sie das erste Ergebnis spezifisch. „Diese Aufgabe lief in dieser Umgebung weiter und erzeugte diesen geprüften Diff“ ist ein nützliches Betriebsurteil. Es zeigt Kollegen, was wiederholbar ist und wo die Bedingungen zählen.

Eine dauerhafte Sitzung sollte Verantwortung leichter nachvollziehbar machen

VS Code 1.144 verlagert mehr Agentenarbeit in einen fortlaufenden Arbeitsbereich: dorthin, wo Anweisungen zu Aktionen und Aktionen zu prüfbaren Änderungen werden. AHP gibt Clients eine Richtung für gemeinsamen Zustand; der Ausführungsort bestimmt, was nach Gerätetrennung weiterläuft.

Die bedeutsame Verbesserung ist eine Aufgabe, die Sie verlassen, wieder öffnen und weiterhin verstehen können. Bewahrt die Sitzung Quellzustand, Entscheidungen und Prüfungen, wird der Laptopdeckel zum Planungsdetail statt zur Arbeitsgrenze.

Quellen

• Versionshinweise zu Visual Studio Code 1.144, stabile Veröffentlichung am 28. Oktober 2026; geprüft am 2. November 2026.
• VS Code Wrapped: GitHub Universe 2026, 28. Oktober 2026.
• Microsoft Agent Host Protocol, Spezifikation v1.0.0 und Überblick zum gemeinsamen Zustand, geprüft am 2. November 2026.

Bewahren Sie das Material hinter einer Entscheidung auf

Telli.sh ist eine Möglichkeit, autorisiertes Quellenmaterial zusammen mit bereits geprüften Notizen aufzubewahren. Notizbereich anlegen.