Wie wird der VS Code Agent Host auf einem Cloud-Mac bereitgestellt? Anleitung 2026

Ein Agent Host kann laut offizieller VS-Code-Architekturbeschreibung als lokaler Prozess oder als unabhängiger Remote-Dienst laufen und mehrere Clients an eine Sitzung anbinden. Symptom: Ihr lokales VS-Code-Fenster verschwindet, während ein langer Copilot-, Claude- oder Codex-Lauf noch arbeitet. Schnellste Lösung: Betreiben Sie den Agent Host auf einem isolierten Cloud-Mac nahe Repository und Xcode-Toolchain, verbinden Sie ihn über genau einen verwalteten SSH- oder Entwicklungstunnel und führen Sie jede Aufgabe in einem eigenen Git-Arbeitsbaum aus. Sitzungsfortbestand ist dabei keine Sicherheitsisolation.

Diese Anleitung ist für iOS- und macOS-Entwickler gedacht, die lange Aufgaben in Xcode-Projekten ausführen lassen, für Plattformingenieure mit mehreren entfernten Agent-Sitzungen sowie für AI-Coding-Verantwortliche, die eine belastbare Alternative zu einem dauerhaft belegten lokalen Mac bewerten. Wenn Sie nur kurze Codevorschläge ohne macOS-spezifische Tests benötigen, ist ein Cloud-Mac wahrscheinlich unnötig.

Zuletzt aktualisiert am 03.09.2026; die Funktionsangaben wurden anhand der offiziellen VS-Code-Architektur-, Sitzungs-, Remote-Verbindungs- und MCP-Dokumentation sowie der Apple-Xcode-Referenzen geprüft.

Vor dem Start: Agent Host, Harness und Cloud-Mac sauber trennen

Der wichtigste Architekturfehler besteht darin, alle Komponenten als „Agent“ zu behandeln. Der Agent Host hält Sitzungen, nimmt Verbindungen von Clients an und startet beziehungsweise verwaltet den Agent Harness. Das Harness führt die eigentliche Aufgabenlogik aus. Der Modellanbieter liefert Antworten oder Aktionen, ist aber weder automatisch für die Dateisicherheit noch für die Lebensdauer des entfernten Prozesses zuständig. VS Code und weitere Fenster sind Clients; der Cloud-Mac stellt schließlich Dateisystem, Shell, Xcode, Simulator, Schlüssel und lokale Werkzeuge bereit.

Diese Trennung beantwortet auch die erste Betriebsfrage: Der Host kann weiterlaufen, wenn der lokale Rechner ausgeschaltet wird, aber nur dann, wenn er wirklich als unabhängiger Prozess auf dem Remote-System eingerichtet wurde. Ein Editorfenster, das lediglich eine Verbindung offen hält, ist kein dauerhafter Dienst. Die Dokumentation zur Verwaltung von Sitzungen sollte deshalb neben der Architekturdefinition als verbindliche Referenz für den Pilotbetrieb dienen.

Prüfen Sie vor der Bereitstellung diese Grenzen:

• Repository: Liegt der Quellcode direkt auf dem Cloud-Mac, in einem gemounteten Verzeichnis oder wird er bei jedem Lauf synchronisiert? Für lange Aufgaben ist ein lokaler Arbeitsstand auf dem Mac meist besser kontrollierbar als ein instabiles Netzlaufwerk.
• Werkzeuge: Darf der Agent nur Git, Tests und Build-Befehle ausführen, oder auch Paketmanager, Simulator, Browser und MCP-Server starten?
• Berechtigungen: Verwenden Sie keine persönlichen Dauerschlüssel, wenn ein begrenztes Dienstkonto oder ein kurzlebiges Token genügt. Zugangsdaten für Repository, Signierung und Cloud-Dienste müssen getrennt behandelt werden.
• Sicherheitsgrenze: Ein isolierter Arbeitsbaum schützt vor gegenseitigen Änderungen, ersetzt aber keine macOS-Benutzertrennung, Prozessbegrenzung oder Prüfung gefährlicher Shell-Befehle.
• Rückbau: Definieren Sie vor dem ersten Lauf, wer Arbeitsbäume löscht, Tokens widerruft, Logs archiviert und einen kompromittierten Host außer Betrieb nimmt.

Braucht Ihr Projekt weder Xcode noch Simulator, Signaturwerkzeuge noch macOS-spezifische Tests, sollten Sie zuerst eine andere Ausführungsumgebung bewerten. Ein Cloud-Mac ist dann keine technische Notwendigkeit, sondern eine zusätzliche Betriebsfläche.

Erster Entscheidungspunkt: SSH oder Entwicklungstunnel

Wählen Sie nicht beide Verbindungswege gleichzeitig für den Produktivbetrieb. Eine doppelte Erreichbarkeit erschwert die Frage, welcher Zugang im Notfall geschlossen werden muss. SSH passt zu Teams mit vorhandener Schlüsselrotation, zentralen Nutzerkonten und kontrollierten Firewall-Regeln. Ein Entwicklungstunnel kann sinnvoller sein, wenn der Mac nicht als direkt erreichbarer SSH-Endpunkt veröffentlicht werden soll. Die Sicherheitsdokumentation für Remote Tunnels beschreibt die dafür relevanten Identitäts- und Netzwerkbedingungen.

Der bessere Weg ist derjenige, den Ihr Team dauerhaft überwachen kann. Dokumentieren Sie Hostname oder Tunnelkennung, verantwortliche Identität, Startmethode und den Zeitpunkt der ersten erfolgreichen Verbindung. Verwenden Sie die Dokumentation für entfernte Agent-Sitzungen, um die unterstützte Client-Verbindung gegen Ihre konkrete VS-Code-Version abzugleichen. Funktionen im Insiders-Kanal oder im Agent Host Protocol können sich während der Weiterentwicklung ändern; behandeln Sie eine Vorschau nicht als stabile Unternehmenszusage.

Erste Stunde: Einen kontrollierbaren Remote-Host herstellen

Arbeiten Sie die folgende Reihenfolge ab. Jeder Schritt benötigt einen Nachweis, und jeder Stoppgrund muss vorab feststehen.

1. Version und Funktionsstatus festhalten. Notieren Sie die verwendete VS-Code-Ausgabe, den Kanal, die aktivierten Agent-Funktionen und die gewählte Host-Implementierung. Prüfen Sie die AI-Einstellungen von VS Code, statt Schalter aus einem fremden Beispiel zu übernehmen. Stoppen Sie, wenn die benötigte Funktion nur als Vorschau verfügbar ist und Ihr Team keinen Vorschau-Rollout freigegeben hat.

2. Den Cloud-Mac vorbereiten. Legen Sie ein eigenes Arbeitskonto oder eine klar begrenzte Betriebsidentität an, installieren Sie Git, die für das Projekt erforderliche Xcode-Toolchain und nur die benötigten Zusatzprogramme. Der Host sollte nicht mit einem privaten Entwicklerprofil, globalen Cloud-Schlüsseln oder unnötigen Administratorrechten laufen.

3. Repository und Arbeitsverzeichnis festlegen. Klonen Sie das Repository in einen kontrollierten Pfad und definieren Sie, ob der Host direkt dort oder ausschließlich in Arbeitsbäumen schreiben darf. Halten Sie die Ausgangsrevision fest. Der Nachweis ist ein reproduzierbarer Git-Status vor dem Start; der Stoppgrund ist ein unerwarteter lokaler Änderungsstand, den niemand zuordnen kann.

4. Eine Verbindungsroute einrichten. Konfigurieren Sie entweder SSH oder den Entwicklungstunnel, nicht eine zufällige Mischung aus beiden. Testen Sie Anmeldung, Host-Start und Client-Verbindung mit einem unkritischen Verzeichnis. Speichern Sie keine privaten Schlüssel in Repository-Dateien oder in einer Agent-Anweisung.

5. Den Host unabhängig vom Editor starten. Der Start muss so dokumentiert sein, dass ein Plattformmitglied ihn nach einem lokalen Verbindungsabbruch wiederfinden und kontrolliert beenden kann. Prüfen Sie, ob der Prozess nach dem Schließen des VS-Code-Fensters sichtbar bleibt. Wenn er sofort endet, ist die Sitzung nicht unabhängig genug für einen Langlauf.

6. Einen Baseline-Nachweis sichern. Speichern Sie Sitzungskennung, Repository-Revision, Host-Startzeit, Verbindungsmethode und die Ausgabe eines harmlosen Diagnosebefehls. Ein Pilot ohne diese Belege lässt sich später nicht von einem zufällig erfolgreichen Test unterscheiden.

Die erste Stunde ist beendet, sobald eine zweite Person den Host über die dokumentierte Route findet und den Zustand nachvollziehen kann. Fehlt diese Übergabe, sollten Sie nicht mit produktiven Agent-Aufgaben fortfahren.

Zweiter Entscheidungspunkt: Harness und Arbeitsbaum statt gemeinsames Hauptverzeichnis

GitHub Copilot, Claude und Codex sind keine austauschbaren Schalter. Prüfen Sie für jedes Harness den Kontozugang, den Modellzugang, die verwendeten Einstellungen und die Frage, ob Aktionen eine menschliche Bestätigung verlangen. Besonders experimentelle Funktionen des Agent Host Protocol oder clientseitige Erweiterungen dürfen nicht stillschweigend als Host-Funktionen behandelt werden.

Erstellen Sie für die erste Aufgabe einen separaten Arbeitsbaum mit verständlichem Namen und referenzierter Ausgangsrevision. Lassen Sie den Agent nur eine kleine, reversible Änderung vornehmen: etwa einen begrenzten Test, eine klar abgegrenzte Fehlerkorrektur oder eine dokumentierte Build-Anpassung. Verlangen Sie anschließend einen Diff, den Testbefehl und eine Erklärung aller neu erzeugten Dateien.

Prüfen Sie danach drei Pfade: Commit, Verwerfen und Wiederherstellen. Ein Commit muss eindeutig dem Arbeitsbaum zugeordnet sein; beim Verwerfen dürfen weder der Hauptbaum noch ein anderer Lauf verändert werden; bei der Wiederherstellung muss der Host die Sitzung mit dem ursprünglichen Kontext wiederfinden. Wenn der Agent direkt in das Hauptverzeichnis schreibt, behandeln Sie das nicht als kosmetische Abweichung, sondern als fehlende Isolationskontrolle.

Nach dem Trennen: Sitzungsfortbestand und Mehrfenster-Abnahme

Starten Sie eine repräsentative, aber risikoarme Aufgabe und warten Sie, bis sie nachweisbar arbeitet. Trennen Sie anschließend das lokale Fenster, nicht nur den Fokus der Anwendung. Prüfen Sie, ob der Remote-Prozess weiterläuft, ob Terminalausgaben fortgeschrieben werden und ob der Agent seinen Zwischenstand behält. Die offizielle Beschreibung entfernter Sitzungen ist hier maßgeblicher als Beobachtungen aus Community-Beiträgen.

Verbinden Sie sich über ein zweites VS-Code-Fenster oder einen ausdrücklich unterstützten Browserzugang. Vergleichen Sie:

• Sitzungsstatus und letzte Aktion,
• Terminalausgabe und laufenden Prozess,
• Git-Diff und neu angelegte Dateien,
• offene Bestätigungsanfragen,
• sichtbaren Kontext und zuletzt übermittelte Anweisung.

Ein zweites Fenster sollte zunächst Beobachterstatus haben. Geben Sie nicht aus beiden Fenstern gleichzeitig Schreibanweisungen, weil eine gemeinsame Sitzung zwar mehrere Clients unterstützen kann, aber keine automatische Konfliktauflösung für widersprüchliche Eingaben verspricht.

Testen Sie Fehler getrennt, weil sie unterschiedliche Ursachen haben:

1. Lokale Netzwerkunterbrechung bei weiterlaufendem Cloud-Mac.
2. Neustart des entfernten Macs.
3. Beendigung oder Absturz des Agent-Host-Prozesses.
4. Ablauf oder Entzug einer verwendeten Zugangserlaubnis.

Der Nachweis muss jeweils zeigen, ob die Sitzung fortgesetzt, sauber beendet oder manuell wiederhergestellt wurde. Stoppen Sie die Ausweitung des Piloten, wenn ein Neustart nur durch direkte, nicht dokumentierte Handarbeit gelingt oder wenn der zweite Client einen veralteten Änderungsstand anzeigt.

Betriebshinweis: „Editor geschlossen“ ist kein ausreichender Wiederanlauftest. Erst die Kombination aus Netzwerkverlust, Mac-Neustart und Host-Prozessende zeigt, welche Komponente tatsächlich dauerhaft arbeitet.

Xcode, Browser und MCP: Von der Codeänderung zum lieferbaren Ergebnis

Ein Agent kann Quelltext erzeugen, ohne dass daraus ein auslieferbares macOS- oder iOS-Artefakt entsteht. Verwenden Sie deshalb ein kleines echtes Projekt mit begrenztem Risiko und prüfen Sie die gesamte Kette: Abhängigkeiten, Build, Tests, erzeugte Dateien und Aufräumen. Für die verfügbaren Kommandozeilenwerkzeuge ist die Apple-Referenz zu Xcode Command Line Tools die verbindliche Grundlage; verwenden Sie keine lokal kopierten Befehlslisten ohne Versionsabgleich.

Führen Sie mindestens diese Kontrollen aus:

• Ist die erforderliche Xcode-Version installiert und für das Betriebsprofil freigegeben?
• Findet der Agent das richtige SDK, Projekt oder Workspace?
• Kann der Build ohne interaktive Eingabe starten?
• Werden Testresultate und Logs an einem bekannten Ort erzeugt?
• Werden Signaturmaterial und Provisioning-Daten nur für den konkreten Zweck verfügbar gemacht?
• Werden abgebrochene Simulatoren, temporäre Dateien und Arbeitsbäume entfernt?

Die Apple-Dokumentation zum Ausführen und Interpretieren von Tests hilft bei der Abnahme von Teststatus und Resultatpfaden. Ein grüner Agent-Dialog ist kein Testnachweis; archivieren Sie stattdessen Befehl, Exit-Status, Ergebnisdatei und relevanten Diff.

MCP verdient eine eigene Prüfung. Der Host kann eine MCP-Konfiguration weiterreichen, aber ein Werkzeug kann an den Client, an eine lokale Erweiterung oder an eine bestimmte Authentifizierung gebunden sein. Vergleichen Sie Ihre Konfiguration mit der offiziellen MCP-Konfigurationsreferenz. Prüfen Sie insbesondere:

• ob der MCP-Server auf dem Cloud-Mac oder beim Client startet,
• welche Umgebungsvariablen und Tokens übertragen werden,
• ob Browserwerkzeuge eine sichtbare Sitzung oder interaktive Eingaben verlangen,
• ob der Agent gefährliche Aktionen nur nach manueller Bestätigung ausführt.

Wenn ein Browser oder ein MCP-Werkzeug nach dem Trennen des lokalen Clients ausfällt, markieren Sie es als clientabhängige Funktion. Der Host-Test bleibt dann zwar für Shell- und Repository-Aufgaben gültig, nicht aber für den vollständigen Workflow.

Erste Betriebswoche: Wiederherstellung, Rechte und Kapazität messen

Nach dem ersten erfolgreichen Langlauf beginnt die eigentliche Abnahme. Führen Sie für jede Sitzung ein knappes Betriebsprotokoll: Harness, Start- und Endzeit, Werkzeugaufrufe, Fehlversuche, manuelle Übernahmen, erzeugte Arbeitsbäume, Build-Resultat und Bereinigung. Zeitangaben und Zählwerte stammen dabei aus Ihren Logs, nicht aus einer allgemeinen Leistungsbehauptung.

Ordnen Sie die Ergebnisse drei Entscheidungen zu:

• Pilot fortsetzen: Sitzungen überleben die geplanten Trennungen, Änderungen sind prüfbar und der Mac lässt sich kontrolliert wiederherstellen.
• Einsatz begrenzen: Die Kernaufgabe funktioniert, aber Browser, MCP, Signierung oder Neustart benötigen noch manuelle Arbeit.
• Rollout stoppen: Arbeitsbäume überschreiben sich, Zugangsdaten bleiben nach dem Lauf aktiv oder der Host ist nach einem Fehler nicht nachvollziehbar wiederherstellbar.

Prüfen Sie außerdem die DSGVO-relevanten Fragen: Welche Repository-Inhalte liegen auf dem Cloud-Mac, wie lange bleiben Logs erhalten, wer kann Terminalausgaben sehen und wie werden Tokens widerrufen? Trennen Sie Sitzungsprotokolle von Quellcode und vermeiden Sie, Geheimnisse in Agent-Ausgaben zu schreiben. Bei einem Vorfall muss klar sein, welcher Benutzer, welcher Arbeitsbaum und welche Verbindung betroffen waren.

Für die Kapazitätsentscheidung zählen nicht nur parallele Fenster. Ermitteln Sie die längste typische Laufzeit, die Zahl gleichzeitiger Arbeitsbäume, Xcode-Buildspitzen, Simulatorbedarf, Speicherbedarf durch Abhängigkeiten und die Zeit für Wiederherstellung. Lesen Sie dazu auch den Kapazitätsleitfaden für Remote-Entwicklung auf Mac-Systemen. Ein geteilter Mac kann für klar getrennte, kurze Aufgaben genügen; ein eigener Mac pro lang laufendem oder signierungsnahen Workflow ist leichter zu kontrollieren, kostet aber ungenutzte Kapazität, wenn die Auslastung stark schwankt.

Wenn Ihr Ablauf regelmäßig unbeaufsichtigte Builds benötigt, vergleichen Sie zusätzlich die Hinweise zum automatisierten Xcode-Build auf einem Cloud-Mac mit Ihrer tatsächlichen Toolchain. Für Fragen zu Zugang, Betriebsgrenzen und Rückbau finden Sie die passenden MacPull-Hilfeinformationen.

Was Sie nach der Abnahme entscheiden sollten

Der aktuelle Ansatz mit einem lokalen Editor und einem gemeinsam genutzten Entwicklungsrechner hat drei konkrete Schwächen: Er endet leicht mit dem Clientfenster, er vermischt persönliche Zugangsdaten mit Projektzugriffen und er lässt parallele Agent-Änderungen im selben Verzeichnis schwer nachvollziehbar werden. Ein lokaler Mac ist außerdem nicht automatisch verfügbar, wenn ein Teammitglied offline ist oder ein Simulator- beziehungsweise Xcode-Lauf länger dauert.

Ein Cloud-Mac mit unabhängigem Agent Host ist deshalb für temporäre Langläufe, reproduzierbare Arbeitsbäume und kontrollierte Xcode-Prüfungen oft die sauberere Betriebsform. Das gilt aber nicht pauschal: Für dauerhaft hohe Grundlast, zwingende physische Geräteanschlüsse oder streng lokale Entwicklungsdaten kann der eigene Mac die bessere Wahl bleiben. Wenn Sie zunächst nur eine belastbare Testumgebung für Sitzungsfortbestand, parallele Arbeitsbäume und Xcode-Abnahme benötigen, können Sie bei MacPull eine passende Mietumgebung prüfen, bevor Sie eine dauerhafte Hardwareflotte binden. Starten Sie erst nach den beschriebenen Rückfalltests und wählen Sie anschließend zwischen gemeinsamem Pool und aufgabenbezogener Isolation anhand Ihrer gemessenen Laufzeiten und Buildspitzen.

Häufige Fragen