GitHub startet eine verbundene Copilot-Cloud mit fortsetzbaren Agenten-Sitzungen

Was GitHub offiziell angekuendigt hat

GitHub hat am 28. Oktober 2026 eine neue, verbundene Copilot-Cloud vorgestellt. Eine Agenten-Sitzung kann auf github.com, in GitHub Mobile, der Copilot CLI, der Copilot-App oder in Visual Studio Code beginnen und spaeter auf einer anderen Oberflaeche fortgesetzt werden.

Auch Slack und Microsoft Teams sind eingebunden. Dort kann ein Nutzer GitHub erwaehnen, um beispielsweise ein Issue anzulegen, eine Codeaenderung anzufordern oder einen Fehler untersuchen zu lassen. Die neue Cloud-Erfahrung und die zugehoerigen Sandboxes sind laut GitHub fuer bezahlte Copilot-Plaene allgemein verfuegbar und werden seit dem 28. Oktober ausgerollt.

Das ist eine bestaetigte Plattformaenderung. GitHub verspricht damit jedoch nicht, dass jede Aufgabe ohne Rueckfragen, Fehler oder menschliche Kontrolle abgeschlossen wird.

Allgemeine Verfuegbarkeit gilt fuer bezahlte Copilot-Plaene und einen laufenden Rollout. Copilot Free behaelt Chat auf github.com und Mobile, erhaelt die neue Cloud-Erfahrung aber nicht ohne Upgrade.

Eine Sitzung ueber Web, Mobile und Entwicklungswerkzeuge

Der Kern des Releases ist ein gemeinsamer Sitzungszustand. GitHub beschreibt, dass dieselbe Aufgabe auf dem Smartphone per Sprache oder Bild gestartet, im Web weiterbearbeitet und anschliessend in der Copilot-App, VS Code oder der CLI abgeschlossen werden kann. Die Sitzungsliste und angeheftete Sitzungen werden zwischen Web und Mobile synchronisiert.

Auf github.com kann Copilot den geoeffneten Pull Request, eine Datei oder ein Repository als Kontext aufnehmen. In GitHub Mobile lassen sich Aufgaben aus einem Pull Request, Issue oder Repository heraus starten. Fuer Aenderungen waehlt der Nutzer ein Repository; Fragen koennen laut GitHub auch mehrere Repositories einer Organisation einbeziehen.

Lokale Sitzungen lassen sich ebenfalls vom Telefon aus steuern. Dazu muss das lokale Geraet ueber GitHub Mission Control in der Copilot CLI oder in VS Code als Umgebung registriert werden.

Wie die fortsetzbaren Cloud-Sandboxes funktionieren

Standardmaessig laeuft eine Cloud-Sitzung in einer ephemeren, isolierten Sandbox auf GitHub-verwalteter Infrastruktur. Diese Umgebung ist vom lokalen Rechner getrennt und soll schnell starten. GitHub nennt fuer die neue Sandbox keine Begrenzung auf eine Stunde Gesamtlaufzeit.

Wird eine Sandbox heruntergefahren, speichert GitHub einen Snapshot. Dadurch kann die Sitzung spaeter auf einer anderen Oberflaeche fortgesetzt werden. Ein Snapshot ist eine Wiederaufnahmehilfe, aber keine Garantie dafuer, dass externe Systeme, fluechtige Zugangsdaten oder inzwischen veraenderte Abhaengigkeiten unveraendert bleiben.

Wer bereits Actions-basierte selbst gehostete Runner oder eine copilot-setup-steps.yml verwendet, muss laut GitHub weiterhin Actions als Sitzungsumgebung nutzen. Alternativ kann ein eigener Rechner oder Server ueber den CLI-Schalter --environment-host als selbst gehostete Umgebung registriert werden.

Werkzeuge, MCP, Skills und Berechtigungen

Cloud-Sitzungen erhalten Bash, GitHub CLI und Codesuche. Zusaetzlichen Kontext koennen integrierte Konnektoren unter anderem aus Sentry, Linear und Cloudflare liefern. GitHub nennt ausserdem lokale oder entfernte eigene MCP-Server mit schluesselbasierter Authentifizierung.

Agent Skills koennen wiederholbare Arbeitsablaeufe mit Anweisungen, Skripten und Ressourcen beschreiben. Slash-Commands wie /rubber-duck und /context stehen nun auch auf github.com und in GitHub Mobile bereit.

GitHub betont ein Berechtigungsmodell, bei dem Nutzer den Autonomiegrad waehlen und Copilot vor genehmigungspflichtigen Werkzeugaufrufen nachfragen soll. Fuer produktive Nutzung bleibt entscheidend, welche Repository-, Netzwerk- und Fremdsystemrechte tatsaechlich freigegeben sind.

Was sich bei Compute und Abrechnung aendert

GitHub fuehrt das enthaltene Actions-Compute-Kontingent als gemeinsamen, geldbasierten Pool. Er kann fuer standardmaessige GitHub-hosted Runner, Copilot-Cloud-Sandboxes und bei Team sowie Enterprise Cloud auch fuer groessere Hosted Runner eingesetzt werden.

Jedes Produkt behaelt seinen veroeffentlichten Tarif. Hoeher bepreiste Rechenleistung verbraucht das gemeinsame Kontingent daher schneller. Das Kontingent wird zu Beginn jedes Abrechnungszeitraums zurueckgesetzt; darueber hinausgehende Nutzung folgt den bestehenden Preisen, Budgets und Zahlungseinstellungen.

Die Abrechnung fuer Cloud-Sandbox-Nutzung beginnt nach GitHubs Ankuendigung im November 2026. Die Meldung nennt keine pauschalen Eurobetraege, weil Umfang und Rate vom Plan und vom genutzten Compute-Typ abhaengen. Aktuelle Preise muessen deshalb vor einem groesseren Einsatz in der GitHub-Dokumentation geprueft werden.

Zugriff, Mandantentrennung und offene Sicherheitsfragen

Der Zugriff auf Copilot in der Cloud wird ueber die Richtlinie 'Copilot in the cloud' gesteuert. Bestehende Repository-Ausschluesse des frueheren Cloud-Agenten sollen in die neue Erfahrung uebernommen werden. Unternehmensweite Regeln fuer Agentenberechtigungen und MCP-Allowlisten gelten laut GitHub ebenfalls weiter.

Chat-Sitzungen sind standardmaessig auf eine Organisation oder auf persoenliche Repositories begrenzt. Bei Organisations-Repositories ist Single Sign-on fuer den Sitzungszugriff erforderlich. Fehlt einem Nutzer Schreibzugriff auf das betrachtete Repository, soll Copilot dort automatisch nur lesend arbeiten.

Diese Kontrollen reduzieren Risiken, ersetzen aber keine eigene Pruefung von Geheimnissen, ausgehenden Netzwerkzugriffen, Drittanbieter-Konnektoren und vorgeschlagenen Codeaenderungen. Die Ankuendigung enthaelt keine vollstaendige technische Sicherheitsbewertung oder Fehlerraten fuer agentische Aktionen.

• Cloud-Richtlinie und Repository-Ausschluesse vor dem Rollout pruefen
• MCP-Server und Konnektoren auf minimal notwendige Rechte begrenzen
• Budgets und Kostenwarnungen fuer das gemeinsame Compute-Kontingent setzen
• Agenten-Aenderungen weiterhin ueber Branches, Tests und Reviews absichern
• Keine Produktivgeheimnisse in unkontrollierte Sitzungen oder Prompts kopieren

Warum das Release fuer KI-Agenten relevant ist

GitHub verschiebt Copilot von einzelnen Oberflaechen zu einer fortsetzbaren Agenten-Sitzung, die ihren Kontext und ihre Ausfuehrungsumgebung ueber Geraete hinweg behaelt. Das macht laenger laufende Entwicklungsaufgaben weniger an einen bestimmten Rechner oder Editor gebunden.

Die Verbindung aus Cloud-Sandbox, Repository-Kontext, MCP, Skills und mobilen Steuermoeglichkeiten ist ein wichtiger Plattformschritt. Sie bringt zugleich neue Governance-Fragen mit sich: Wer darf welche Umgebung starten, welche Daten duerfen Konnektoren lesen und wie werden Kosten sowie agentische Aenderungen kontrolliert?

Die MindrAils-Einordnung: Die neue Copilot-Cloud kann Arbeitsablaeufe vereinfachen, ist aber kein Ersatz fuer reproduzierbare Entwicklungsumgebungen, CI-Pruefungen und menschliche Freigaben. Ihr praktischer Wert wird sich an Zuverlaessigkeit, Kostenkontrolle und sicherer Rechtevergabe messen lassen.

Ein sinnvoller Testplan fuer Teams

Teams sollten mit einem begrenzten Repository und einer klar definierten Aufgabe beginnen, etwa einer kleinen Fehleranalyse oder einer dokumentierten Codeaenderung. Dabei sollte festgehalten werden, welche Oberflaechen genutzt, welche Werkzeuge aufgerufen und welche Berechtigungen angefordert wurden.

Ein zweiter Test sollte die Wiederaufnahme pruefen: Sitzung starten, Sandbox herunterfahren lassen und auf einem anderen Geraet fortsetzen. Dabei sind verlorener Kontext, nicht reproduzierbare Abhaengigkeiten, offene Aenderungen und der tatsaechliche Compute-Verbrauch zu dokumentieren.

Vor breiter Freigabe sollten Administratoren Organisationsgrenzen, SSO, Repository-Ausschluesse, MCP-Allowlisten, Budgetgrenzen und den Review-Prozess gemeinsam testen. So wird aus einer interessanten Agentenfunktion ein kontrollierbarer Entwicklungsprozess.