Neue GitHub-Copilot-App soll Chaos bei agentengetriebener Entwicklung bändigen

GitHub hat im Rahmen der Microsoft Build 2026 eine eigenständige Desktop-Anwendung für seinen KI-Assistenten Copilot vorgestellt. Wie das Unternehmen in der Ankündigung ausführt, soll die Copilot-App als zentrale Oberfläche dienen, über die sich mehrere KI-Agentensitzungen parallel starten, beobachten und steuern lassen. Verfügbar ist die Software zunächst als Technical Preview für Abonnenten der Tarife Copilot Pro, Pro+, Business und Enterprise. In den beiden Business-Plänen müssen Administratoren vorab Preview-Funktionen sowie die Copilot-CLI in den Richtlinieneinstellungen freischalten.

Als Motivation hinter der neuen App führt GitHub in seinem Blog an, dass die bislang verfügbaren Werkzeuge nicht auf den parallelen Einsatz mehrerer Agenten ausgelegt seien. Kontextinformationen verteilten sich über verschiedene Fenster, laufende Prozesse seien schwer nachzuverfolgen, und von Agenten erzeugter Code lande in Pull-Requests, ohne dass die Vorgeschichte dokumentiert sei. Nach Angaben des Unternehmens hat sich die Zahl der Commits auf der Plattform im Jahresvergleich nahezu verdoppelt und liegt bei mehr als 1,4 Milliarden pro Monat, parallel werden über zwei Milliarden Minuten GitHub Actions pro Woche verbraucht. Daraus leitet GitHub die Notwendigkeit ab, die zugrunde liegenden Systeme für agentengetriebene Arbeitsabläufe zu härten.

My Work und isolierte Worktrees pro Sitzung

Zentrales Element der Anwendung ist eine Ansicht namens „My Work“. Sie führt aktive Agentensitzungen, Issues, Pull-Requests und Hintergrundautomatisierungen aus mehreren Repositories in einer gemeinsamen Oberfläche zusammen. Damit sollen Entwicklerinnen und Entwickler auf einen Blick erkennen, wo Handlungsbedarf besteht – etwa wenn ein Agent einen Bug in der Produktion analysiert, ein zweiter eine Backlog-Aufgabe abarbeitet und ein dritter Feedback aus einem Code-Review umsetzt. Über einen Posteingang lassen sich aus offenen Issues oder Pull-Requests direkt neue Sessions starten, ohne zwischen Browser-Tabs und lokalen Werkzeugen wechseln zu müssen.

Technisch läuft jede Agentensitzung in einem eigenen git worktree, also einer realen, isolierten Kopie des jeweiligen Branches. Dadurch sollen mehrere Agenten parallel an demselben Repository arbeiten können, ohne sich gegenseitig Änderungen zu überschreiben. Die App verwaltet diese Worktrees laut GitHub vollständig selbst: Sie legt sie automatisch an, trennt sie pro Session und entfernt sie nach Abschluss wieder. Allerdings verhindere diese Architektur Merge-Konflikte nur innerhalb der einzelnen Arbeitsverzeichnisse; beim späteren Zusammenführen in gemeinsame Branches könnten divergierende Änderungen weiterhin zu Konflikten führen. Zudem belegen parallele Worktrees lokale Ressourcen wie Speicherplatz und Dateihandles – das sollten Entwicklungsteams bei CI- und Backup-Konzepten unbedingt berücksichtigen.

Agent Merge und bestehende Freigaberegeln

Mit „Agent Merge“ hat GitHub zudem eine Funktion vorgestellt, die Pull-Requests durch Review, Continuous Integration und Merge begleiten soll. Das Werkzeug überwacht die CI-Pipelines, verfolgt erforderliche Reviewer, reagiert auf fehlgeschlagene Checks und wartet, bis alle Bedingungen erfüllt sind. Für Organisationen mit etablierten CI/CD-Prozessen betont der Hersteller, dass bestehende Review- und Merge-Anforderungen weiterhin gelten. Branch Protection Rules, verpflichtende Status-Checks und Reviewer-Vorgaben blieben aktiv. Teams können laut Ankündigung konfigurieren, wie weit Agent Merge eingreifen darf – ob es lediglich CI-Läufe wiederholt, Feedback aus Reviews umsetzt oder unter definierten Bedingungen auch automatisch Merges vollzieht.

Standardmäßig fordert der Cloud-Agent vor jedem schreibenden Vorgang eine Erlaubnis ein, etwa vor dem Anlegen eines Issues oder dem Hinterlassen eines Kommentars. Erst wenn ein Team genügend Vertrauen in die Automatisierung gefasst hat, lässt sich ein Autopilot-Modus aktivieren. GitHub betont, dass die Verantwortung für Richtlinien und für die Frage, welche Automatisierungen erlaubt sind, bei den jeweiligen Organisationen bleibt. Für mehr Nachvollziehbarkeit sollen sogenannte „Canvases“ sorgen. Damit sind bidirektionale Arbeitsflächen für Menschen und Agenten gemeint, auf denen Pläne, Zwischenstände und Entscheidungen sichtbar bleiben, anstatt im Chatverlauf unterzugehen.

Sandboxes, erweitertes Code-Review und SDK

Ergänzend führt GitHub lokale und cloudbasierte Sandboxes ein, in denen Agenten Code ausführen, testen und iterieren sollen, ohne bereits Produktivsysteme zu berühren. Bei lokaler Ausführung läuft Copilot in einer isolierten Umgebung mit eingeschränktem Zugriff auf das Dateisystem, das Netzwerk und die Systemfunktionen. Cloud-Sandboxes nutzen dazu kurzlebige Linux-Umgebungen, die GitHub selbst betreibt. Die Richtlinien dafür legen Organisationen jeweils selbst fest – ein Punkt, der für Unternehmen mit strengen Compliance-Anforderungen relevant sein dürfte.

Die Copilot-Code-Review wurde um einen „Medium Tier“ erweitert, der Pull-Requests an ein leistungsfähigeres Modell weiterreicht. Auf Repository-Ebene können Administratoren entscheiden, ob ein kostengünstigeres oder ein präziseres Modell eingesetzt wird, etwa stärkere Modelle für sicherheitskritische Codebasen. Ergänzt wird das Review durch spezielle Skills wie /security-review und /rubberduck. Das GitHub-Copilot-SDK steht ab sofort generell zur Verfügung (GA), unter anderem für Node.js, Python, Go, .NET, Rust und Java. Teams sollen damit eigene agentische Werkzeuge auf demselben Runtime-Unterbau entwickeln können.

Auch die Copilot-CLI hat GitHub überarbeitet. Eine neue textbasierte Oberfläche mit Tabs gehört ebenso zu den Neuerungen wie eine On-Device-Spracherkennung, bei der Audiodaten das Gerät nach Angaben des Anbieters nicht verlassen, sowie geplante Aufgaben über den Befehl /every. Als Partner im Ökosystem nennt GitHub unter anderem LaunchDarkly, PagerDuty, Sonar und Miro, die als Agent-Apps in Copilot integriert werden sollen.

(map)