Was ist die GitHub Copilot App? Funktionen, Workflows und Zielgruppen 2026

Am Ende einer einzigen Entwicklungsaufgabe können heute bereits drei getrennte Arbeitsstränge gleichzeitig offen sein: ein Agent untersucht einen Fehler, ein zweiter bereitet eine Funktion vor und ein dritter prüft eine Pull Request. Die eigentliche Frage ist deshalb nicht mehr nur, ob ein KI-Assistent Code erzeugen kann. Entscheidend ist, ob Sie mehrere laufende Aufgaben nachvollziehbar steuern, voneinander isolieren und anschließend sauber in den Entwicklungsprozess zurückführen können.

Genau an diesem Punkt beginnt die Suche nach einer Antwort auf die Frage: Was ist die GitHub Copilot App? Handelt es sich lediglich um eine weitere Chat-Oberfläche für Code oder um einen eigenständigen Arbeitsplatz für agentengesteuerte Entwicklung? Die Antwort erschließt sich erst, wenn man nicht einzelne Funktionen, sondern den gesamten Weg von Issue über Codeänderung bis zum Pull Request betrachtet.

Was ist die GitHub Copilot App und welches Problem löst sie?

Die GitHub Copilot App ist eine Desktop-Anwendung für agentengesteuerte Softwareentwicklung. Sie bündelt Agent-Sitzungen, Repository-Arbeit, Branches, Issues, Pull Requests, CI-Prüfungen und wiederkehrende Automatisierungen in einer gemeinsamen Oberfläche. GitHub beschreibt sie ausdrücklich als Arbeitsbereich, der den Wechsel zwischen Terminal, Entwicklungsumgebung und Browser reduzieren soll. (docs.github.com)

Ein klassischer Codeassistent unterstützt Sie meistens dort, wo Sie gerade schreiben. Die GitHub Copilot App setzt früher und später im Prozess an:

• Sie wählen eine konkrete Aufgabe aus einem Issue oder einer Pull Request aus.
• Sie weisen einem Agenten einen Arbeitsauftrag zu.
• Die Aufgabe läuft in einem eigenen Arbeitsbereich und Branch.
• Sie prüfen Änderungen, Tests und Ergebnisse.
• Anschließend erstellen, prüfen oder übernehmen Sie die Pull Request.

Damit verschiebt sich die Rolle des Entwicklers. Sie schreiben nicht zwingend jede Zeile selbst, müssen aber Anforderungen präzisieren, Berechtigungen kontrollieren, Änderungen bewerten und die Qualität des Ergebnisses verantworten.

Das löst mehrere praktische Probleme, die bei agentengestützten Workflows schnell sichtbar werden:

1. Kontextwechsel: Ohne zentrale Oberfläche verteilen sich Prompts, Terminalausgaben, Branches, Issues und Review-Kommentare auf mehrere Fenster.
2. Branch-Konflikte: Wenn mehrere Aufgaben im selben lokalen Arbeitsverzeichnis landen, können Änderungen, Abhängigkeiten und Testzustände vermischt werden.
3. Fehlende Nachvollziehbarkeit: Ein Chat kann erklären, was ein Agent vorhatte, zeigt aber nicht automatisch den vollständigen Weg von der Anforderung bis zur überprüften Änderung.
4. Unklare Verantwortlichkeit: Bei automatischen Änderungen muss klar sein, welcher Mensch den Diff, die Tests und die Berechtigungen geprüft hat.
5. Verdeckte Nutzungskosten: Jede zusätzliche Agent-Sitzung kann AI-Kontingente beanspruchen. Ein unpräziser Auftrag führt daher nicht nur zu mehr Nacharbeit, sondern potenziell auch zu höherem Verbrauch. (docs.github.com)

Die App ist somit nicht einfach „Chat mit Code“. Sie ist eher ein Kontrollzentrum für mehrere Entwicklungsaufträge, bei denen Agenten Aufgaben ausführen und Menschen die Richtung, Freigabe und Abnahme übernehmen.

Welche GitHub Copilot App Funktionen sind 2026 entscheidend?

Die wichtigsten Funktionen sollten nicht als isolierte Checkliste verstanden werden. Ihr Wert entsteht erst im Zusammenspiel.

Parallele Agent-Sitzungen und isolierte Arbeitsbereiche

Jede Sitzung kann in einem eigenen Arbeitsbereich mit eigenem Branch laufen. Dadurch können Sie beispielsweise gleichzeitig einen Fehler reproduzieren lassen, eine Dokumentationsänderung vorbereiten und eine neue API-Funktion untersuchen. GitHub nennt für die App mehrere isolierte Sitzungen, die parallel ausgeführt werden können. (docs.github.com)

Das ist besonders hilfreich, wenn Aufgaben unterschiedliche Risikostufen haben. Eine Rechercheaufgabe sollte nicht denselben lokalen Zustand verändern wie ein Refactoring. Für produktive Arbeit ist außerdem wichtig, Sitzungen nicht nur nach Thema, sondern nach Ziel zu trennen: „Fehler analysieren“, „Patch erstellen“ und „Regressionstest ergänzen“ können drei verschiedene Stationen sein.

Drei Sitzungsmodi statt eines einzigen Autonomiegrades

Die App bietet drei zentrale Sitzungsmodi:

• Interactive: Der Agent arbeitet mit enger Rückkopplung und wartet häufiger auf Ihre Anweisungen.
• Plan: Zuerst wird ein strukturierter Umsetzungsplan erstellt, den Sie prüfen können.
• Autopilot: Der Agent arbeitet weitgehend selbstständig, schreibt Code, führt Prüfungen aus und iteriert. (docs.github.com)

Diese Aufteilung ist für die Risikosteuerung wichtiger als die reine Modellwahl. Für eine unklare Architekturentscheidung eignet sich zunächst der Plan-Modus. Bei einer klar beschriebenen, kleinen Änderung kann Interactive genügen. Autopilot sollte erst eingesetzt werden, wenn Umfang, Testkriterien und erlaubte Dateien eindeutig festgelegt sind.

Modellwahl und eigener Modellschlüssel

Die GitHub Copilot App erlaubt die Auswahl aus mehreren Sprachmodellen sowie die Anpassung des Reasoning-Aufwands. Zusätzlich können konfigurierte Modelle eines eigenen Anbieters über einen eigenen Modellschlüssel, also BYOK, eingebunden werden. (docs.github.com)

Für die Praxis bedeutet das: Nicht jede Aufgabe benötigt das leistungsfähigste Modell. Eine einfache Umbenennung, ein kleiner Test oder eine strukturierte Dokumentation kann mit einem leichteren Modell bearbeitet werden. Komplexe Fehlersuche, Sicherheitsprüfung oder Änderungen über mehrere Module hinweg benötigen dagegen mehr Kontext und häufig höheren Reasoning-Aufwand.

Der eigene Modellschlüssel kann für Organisationen interessant sein, die Modellanbieter, Datenflüsse oder Kostenbudgets getrennt verwalten möchten. Gleichzeitig entsteht eine zusätzliche Verantwortung für Schlüsselverwaltung, Zugriffsbeschränkungen und Datenschutz. Ein Modellschlüssel sollte niemals in Repository-Dateien, Shell-Historien oder frei zugänglichen Konfigurationsdateien landen.

Issues, Pull Requests und CI in einem Ablauf

Die Integration mit GitHub umfasst unter anderem die Suche nach Issues, das Starten von Sitzungen aus Aufgaben, die Erstellung und Prüfung von Pull Requests sowie die Anzeige von CI-Ergebnissen. (docs.github.com)

Der entscheidende Vorteil liegt weniger in der einzelnen Schaltfläche als in der Verbindung der Zustände. Ein Agent kann aus einer konkreten Aufgabe heraus arbeiten, Änderungen in einem Branch vorbereiten und den Übergang zur Pull Request unterstützen. Für Teams wird dadurch sichtbarer, welche Arbeit delegiert wurde und an welcher Stelle menschliche Prüfung erforderlich bleibt.

Was sind Canvases?

Canvases sind interaktive Arbeitsflächen, auf denen Menschen und Agenten gemeinsam an einem sichtbaren Arbeitsartefakt arbeiten. Das kann beispielsweise ein Plan, eine Triage-Ansicht, eine Release-Checkliste, ein Dashboard oder ein Kanban-Board sein. Der Agent kann die Fläche aktualisieren, während Sie Einträge bearbeiten, sortieren oder korrigieren. (docs.github.com)

Der Unterschied zu einem langen Chatverlauf ist erheblich. Ein Chat speichert vor allem Anweisungen und Antworten. Ein Canvas stellt das Ergebnis als veränderbare Oberfläche dar. Für Backlog-Triage, Incident-Abläufe oder Release-Vorbereitung ist das oft verständlicher als eine Folge von Prompts.

Canvases eignen sich besonders dann, wenn eine Aufgabe Struktur, Iteration und Überprüfung benötigt. Über /create-canvas können Sie in einer Agent-Sitzung eine solche Oberfläche beschreiben und anschließend weiterentwickeln. (github.blog)

Automatisierungen und Quick Chats

Wiederkehrende Aufgaben können als Automatisierungen gespeichert und nach Zeitplan oder auf Abruf ausgeführt werden. Denkbar sind beispielsweise eine morgendliche Issue-Triage, die Zusammenfassung offener Pull Requests oder eine wiederkehrende Prüfung definierter Repository-Bereiche. (docs.github.com)

Quick Chats sind dagegen für kurze Vorarbeiten sinnvoll, ohne sofort einen vollständigen Branch oder Arbeitsbereich zu erzeugen. Sie können damit eine Anforderung klären, Risiken sammeln oder den Umfang einer Aufgabe begrenzen, bevor Sie eine ausführende Agent-Sitzung starten.

Welche GitHub Copilot App Verwendungsszenarien sind realistisch?

Neue Funktionen entwickeln

Für eine klar abgegrenzte Funktion kann der Agent zunächst die betroffenen Dateien, Schnittstellen und vorhandenen Tests untersuchen. Danach sollte er einen Plan erstellen, bevor Änderungen vorgenommen werden. Besonders geeignet sind Aufgaben mit eindeutigen Akzeptanzkriterien und einem vorhandenen Testmuster.

Ein guter Auftrag beschreibt nicht nur „Funktion X hinzufügen“, sondern auch:

• Welche Dateien oder Module relevant sind
• Welche Eingaben und Ausgaben erwartet werden
• Welche Tests ergänzt werden müssen
• Welche Dateien ausdrücklich nicht verändert werden dürfen
• Wie die Änderung lokal überprüft werden soll

Fehler analysieren und beheben

Bei einem Fehler sollte der Agent zunächst reproduzieren oder die vorhandenen Logs und Tests untersuchen. Eine sofortige Codeänderung ist häufig der falsche erste Schritt. Besser ist eine Abfolge aus Reproduktion, Hypothese, minimalem Patch und Regressionstest.

Parallel können Sie eine zweite Sitzung für die Recherche eröffnen. Dadurch bleibt die eigentliche Fehlerbehebung isoliert, während die zweite Sitzung mögliche Ursachen, verwandte Module oder historische Änderungen untersucht.

Pull Requests prüfen

Ein Agent kann Änderungen zusammenfassen, potenzielle Randfälle markieren und vorhandene Tests ausführen. Das ersetzt jedoch kein menschliches Review. Besonders kritisch sind Authentifizierung, Berechtigungen, Datenbankmigrationen, externe Schnittstellen und Änderungen an Build- oder Deployment-Prozessen.

Die App ist hier interessant, weil Review, CI-Ergebnis und Agent-Kontext näher zusammenliegen. Die Freigabe muss trotzdem nach Ihren Teamregeln erfolgen.

Repository und Projektstruktur erforschen

Bei unbekannten Projekten kann eine Sitzung ausschließlich zur Orientierung dienen. Lassen Sie sich Abhängigkeiten, zentrale Module, Build-Befehle, Teststrategien und offene Risiken erklären. Erst danach sollte eine ausführende Sitzung gestartet werden.

Dieses Vorgehen reduziert die Gefahr, dass ein Agent auf Grundlage eines falschen mentalen Modells Änderungen an der falschen Stelle vornimmt.

Wiederkehrende Aufgaben automatisieren

Issue-Triage, Statuszusammenfassungen oder einfache Prüfläufe sind geeignete Kandidaten für Copilot automations. Die Automatisierung sollte jedoch ein klar definiertes Ausgabeformat haben. Eine tägliche Zusammenfassung ohne Prioritätsregeln führt schnell zu einer langen, wenig hilfreichen Liste.

Legen Sie deshalb fest, welche Labels, Zeiträume, Statuswerte und Eskalationsbedingungen gelten. Prüfen Sie außerdem regelmäßig, ob sich Repository-Strukturen oder Teamprozesse verändert haben.

Wie unterscheidet sich die App für Einzelentwickler und Teams?

Für Einzelentwickler liegt der größte Vorteil meist in der persönlichen Parallelisierung. Sie können Aufgaben nach Risiko und Ziel trennen, ohne ständig Branches manuell umzuschalten. Ein sinnvoller Ablauf besteht aus einer Recherche-Sitzung, einer Umsetzungssitzung und einer Review-Sitzung.

Für Teams verschiebt sich der Schwerpunkt auf Delegation und Kontrolle. Ein technischer Leiter kann Aufgaben aus Issues an Agenten übergeben, Ergebnisse in Pull Requests bündeln und Review-Schritte standardisieren. Dafür müssen Organisationen klare Regeln definieren:

• Welche Repositorys dürfen Agenten verwenden?
• Welche Aktionen benötigen eine menschliche Freigabe?
• Welche Branches sind geschützt?
• Welche Modelle und eigenen Modellschlüssel sind zugelassen?
• Wie werden AI-Kontingente und Sitzungsaktivitäten überwacht?
• Welche Daten dürfen in Prompts oder externe Modellanbieter gelangen?

Für Enterprise-Umgebungen können zusätzliche Richtlinien greifen. Bei Copilot Business und Enterprise muss die Copilot-CLI-Richtlinie durch einen Administrator aktiviert sein, damit die App genutzt werden kann. (docs.github.com)

Weitere Hinweise zur Einordnung von Agent-Workflows finden Sie in unserem Beitrag über Agent-Entwicklungsmodi im Jahr 2026. Für Teams ist besonders wichtig, Agenten nicht nur nach Geschwindigkeit, sondern nach Prüfpfad, Änderungsumfang und Berechtigungsmodell zu bewerten.

Welche Systeme und Voraussetzungen werden benötigt?

Die Antwort auf die Frage „GitHub Copilot App unterstützt welche Systeme?“ ist derzeit klar: Die Desktop-App unterstützt macOS, Linux und Windows. (docs.github.com)

Zusätzlich benötigen Sie typischerweise:

1. Ein GitHub-Konto mit Copilot-Zugriff: Die App ist laut offizieller Dokumentation für alle Copilot-Pläne verfügbar. Der genaue Funktionsumfang kann jedoch durch Plan, Vorschauphase oder Organisationsrichtlinien begrenzt sein. (docs.github.com)
2. Zugriff auf das gewünschte Repository: Prüfen Sie Leserechte, Schreibrechte, Branch-Schutz und die Berechtigung zum Erstellen von Pull Requests.
3. Eine funktionierende Git-Umgebung: Lokale Sitzungen benötigen ein korrekt eingerichtetes Repository, erreichbare Abhängigkeiten und die für Tests erforderlichen Werkzeuge.
4. Eine Entscheidung über den Ausführungsort: Sitzungen können lokal, in einem neuen Worktree oder in einer Cloud-Sandbox ausgeführt werden. Cloud-Sandboxes laufen isoliert auf von GitHub bereitgestellter Infrastruktur und befinden sich laut Dokumentation in einer öffentlichen Vorschau. (docs.github.com)
5. Organisationsfreigaben: Enterprise-Administratoren können Copilot-CLI-, Agent- oder Modellrichtlinien einschränken.
6. Ein Sicherheitskonzept: Definieren Sie vor dem ersten Autopilot-Lauf, auf welche Dateien, Netzwerke, Secrets und Befehle der Agent zugreifen darf.

Cloud-Sitzungen sind nicht automatisch gleichbedeutend mit einer dauerhaft verfügbaren Entwicklungsmaschine. Sie dienen dazu, Agentenarbeit remote auszuführen. Für lang laufende Build-Prozesse, feste Entwicklungsumgebungen oder macOS-spezifische Toolchains müssen Sie den Ausführungsort separat bewerten. Eine Übersicht zu lokalen Rechnern, Cloud-Ressourcen und dauerhaft verfügbaren Arbeitsplätzen finden Sie in unserem Beitrag über lokale High-End-PCs und Cloud-Entwicklung.

Welche Grenzen und Risiken sollten Sie einplanen?

Generierter Code bleibt prüfpflichtig

Ein Agent kann syntaktisch korrekten Code erzeugen, der fachlich trotzdem falsch ist. Besonders riskant sind implizite Geschäftsregeln, Nebenläufigkeit, Berechtigungsprüfungen und Fehlerbehandlung. Tests müssen daher nicht nur ausgeführt, sondern auf Aussagekraft geprüft werden.

Öffentliche Codeübereinstimmungen sind möglich

GitHub weist darauf hin, dass die App Code erzeugen kann, der öffentlich verfügbarem Code entspricht oder diesem nahekommt. Das kann auch dann vorkommen, wenn eine Richtlinie zur Blockierung von Übereinstimmungen mit öffentlichem Code aktiviert ist. (docs.github.com)

Für Unternehmen bedeutet das: Lizenzprüfung, Herkunftskontrolle und die Dokumentation kritischer Übernahmen gehören weiterhin in den Entwicklungsprozess.

Berechtigungen können zu weit reichen

Eine Sitzung, die Issues lesen, Dateien ändern, Tests ausführen und Pull Requests erstellen darf, besitzt mehr Handlungsspielraum als ein reiner Chat. Verwenden Sie deshalb möglichst geschützte Branches, begrenzen Sie Secrets und vermeiden Sie pauschale Schreibrechte für nicht notwendige Repositorys.

AI-Nutzung ist nicht kostenlos im organisatorischen Sinn

Agent-Sitzungen verbrauchen AI-Kontingente innerhalb des Copilot-Abonnements. Die tatsächlichen Auswirkungen hängen von Modell, Reasoning-Aufwand, Sitzungsdauer und Aufgabenkomplexität ab. (docs.github.com)

Planen Sie deshalb Budgets und Regeln für Autopilot, Automatisierungen und parallele Sitzungen. Eine einfache Aufgabe, die in fünf schlecht abgegrenzten Sitzungen bearbeitet wird, ist organisatorisch und technisch schwerer zu kontrollieren als ein sauber formulierter Auftrag.

Mehrere Sitzungen erhöhen die Verwaltungslast

Parallele Agent-Sitzungen sparen Wartezeit, erzeugen aber zusätzliche Zustände. Benennen Sie Sitzungen nach Repository, Ziel und Status. Schließen Sie veraltete Arbeitsbereiche und führen Sie Änderungen nicht zusammen, bevor Tests und Review abgeschlossen sind.

Wie sieht eine belastbare erste Arbeitsprobe aus?

Für eine erste Bewertung sollten Sie keine kritische Produktionsänderung wählen. Eine kleine, überprüfbare Aufgabe liefert bessere Erkenntnisse über den tatsächlichen Workflow.

Bei einer Hashvps-Arbeitsprobe können Sie beispielsweise so vorgehen:

1. Wählen Sie ein Repository mit vorhandenen Tests und einer klar abgegrenzten Dokumentations- oder Fehlerbehebungsaufgabe.
2. Starten Sie zunächst einen Quick Chat und lassen Sie sich betroffene Dateien, Risiken und Prüfschritte nennen.
3. Eröffnen Sie danach eine Plan-Sitzung in einem neuen Worktree.
4. Prüfen Sie den vorgeschlagenen Plan manuell und korrigieren Sie Annahmen, die nicht zum Projekt passen.
5. Führen Sie die Änderung im Interactive-Modus aus und verlangen Sie nach jedem größeren Schritt eine kurze Begründung.
6. Lassen Sie Tests und gegebenenfalls statische Prüfungen ausführen.
7. Prüfen Sie den Diff, die Testausgabe und die tatsächlich veränderten Dateien.
8. Erstellen Sie erst danach eine Pull Request und dokumentieren Sie, welche Teile durch den Agenten und welche durch Sie geprüft wurden.

Bei dieser Arbeitsprobe sollten Sie keine pauschale Geschwindigkeitszahl versprechen. Die Erfahrung hängt stark von Repositorygröße, Abhängigkeiten, Testabdeckung, Netzwerkzugriff und Modellwahl ab. Aussagekräftiger als eine einzelne Zeitmessung ist die Frage, ob der komplette Pfad von Anforderung über Branch und Validierung bis zur Pull Request nachvollziehbar bleibt.

Für wen ist die GitHub Copilot App geeignet?

Für wen ist die GitHub Copilot App geeignet? Besonders passend ist sie für Entwickler, die mehrere Aufgaben parallel bearbeiten, regelmäßig mit Issues und Pull Requests arbeiten und Agenten nicht nur zum Vervollständigen einzelner Codezeilen einsetzen möchten.

Für Sie ist die App wahrscheinlich interessant, wenn Sie:

• wiederkehrende Entwicklungsaufgaben standardisieren möchten,
• mehrere Repositorys oder Branches gleichzeitig betreuen,
• Agenten mit unterschiedlichen Autonomiegraden einsetzen wollen,
• Pull Requests und CI-Prüfungen in einem Arbeitsablauf bündeln möchten,
• Canvases für Triage, Planung oder Release-Prozesse benötigen,
• als Teamleitung Delegation und Review nachvollziehbarer organisieren möchten.

Weniger geeignet ist sie, wenn Sie ausschließlich Inline-Vervollständigung in einer Entwicklungsumgebung benötigen oder wenn Ihre Organisation Agenten keinen Repository- und Branch-Zugriff erlauben kann. Auch für produktive Änderungen ohne menschliche Prüfung ist sie nicht die richtige Abkürzung.

Benötige ich zwingend einen Copilot-Plan? Die offizielle Dokumentation nennt die App für alle Copilot-Pläne. Für Business- und Enterprise-Nutzer können jedoch Administratorrichtlinien, aktivierte CLI-Funktionen und Repository-Berechtigungen entscheidend sein. (docs.github.com)

Kann ich die GitHub Copilot App ohne lokalen Rechner verwenden? Teilweise. Cloud-Sandboxes können Agent-Sitzungen remote ausführen, befinden sich laut Dokumentation jedoch in der öffentlichen Vorschau. Für dauerhaft verfügbare Entwicklungsumgebungen, feste Toolchains oder bestimmte Systemanforderungen sollten Sie eine separate Remote-Umgebung einplanen. (docs.github.com)

Sind Canvases nur für Projektplanung gedacht? Nein. Sie können als interaktive Oberflächen für Triage, Dashboards, Checklisten, Dokumente oder agentengesteuerte Boards dienen. Ihr Nutzen entsteht dort, wo sichtbare Zustände besser funktionieren als eine lange Folge von Chat-Nachrichten. (docs.github.com)

Lohnt sich dafür eine dauerhaft verfügbare Mac-Umgebung?

Wenn Sie die GitHub Copilot App nur gelegentlich testen, reicht ein vorhandener Rechner häufig aus. Für regelmäßige Agent-Sitzungen, reproduzierbare Builds und zeitversetzte Teamarbeit zeigt sich jedoch schnell die Schwäche einer ausschließlich lokalen Lösung: Der Arbeitsplatz ist an ein einzelnes Gerät gebunden, laufende Sitzungen hängen von Erreichbarkeit und Energieversorgung ab, und macOS-spezifische Tests lassen sich nicht einfach auf jedem System ausführen.

Windows oder Linux bleiben für viele Aufgaben sinnvoll, sind aber nicht immer die beste langfristige Lösung, wenn Ihre Toolchain, Signierung, mobile Entwicklung oder Release-Prüfung macOS voraussetzt. Eine lokale Maschine verursacht außerdem Anschaffungskosten, Wartung, Updates und eine begrenzte Verfügbarkeit für andere Teammitglieder.

Wenn Sie dagegen einen stabilen macOS-Arbeitsplatz nur bei Bedarf oder für bestimmte Projektphasen benötigen, kann das Mieten eines Mac über Hashvps praktischer sein: Sie vermeiden den Kauf zusätzlicher Hardware, behalten eine klar abgegrenzte Entwicklungsumgebung und können den Zugriff für Remote-Arbeit besser in Ihren Ablauf integrieren. Für Teams ist besonders relevant, dass nicht jeder Entwickler dauerhaft eigene leistungsfähige Hardware vorhalten muss. Entscheidend bleibt, die Zugangsdaten, SSH- oder Fernzugriff, Repository-Rechte und DSGVO-Anforderungen sauber zu verwalten.

Bereiten Sie zunächst Ihr Repository, die gewünschten Copilot-Richtlinien und einen kleinen Testauftrag vor. Starten Sie anschließend Ihre erste Agent-Sitzung in einer kontrollierten Umgebung. Wenn Sie für macOS-Entwicklung, Builds oder zeitversetzte Workflows einen verlässlich erreichbaren Rechner benötigen, ist eine Mac-Umgebung von Hashvps der naheliegende nächste Schritt.