GitHub verlangt für Teams-Copilot-Pull-Requests eine dritte Freigabe

Ein @GitHub-Mention macht den Teams-Kanal zur Kommandozentrale

GitHub bindet Copilot jetzt direkt in Microsoft-Teams-Kanäle ein. Gleichzeitig bekommen Repository-Administratoren ein schärferes Kontrollwerkzeug: eine zusätzliche Pflichtfreigabe für Pull Requests, die aus der Teams-Integration stammen. Wer Copilot künftig aus dem Meeting heraus arbeiten lässt, gewinnt damit schnelleren Zugriff auf den Agenten, muss dessen Code aber durch einen härteren Review schleusen, bevor er den Hauptzweig erreicht.

Laut dem Changelog-Eintrag vom 21. August 2026 wird aus einer Teams-Diskussion eine gemeinsame Agentensitzung, die alle Beteiligten sehen und mitsteuern können. Ein @GitHub reicht, egal ob in einem Kanal, einem Thread oder einer Direktnachricht. Mehr Aufwand verlangt GitHub für den Start nicht.

Wer in der Konversation sitzt, darf mitreden. Jede Person kann Fragen stellen, Kontext ergänzen und die Arbeit mitplanen, schreibt GitHub im Beitrag. Nur wer Schreibrechte auf das Repository besitzt, kann Copilot tatsächlich zu Änderungen anstoßen; Beobachten und Ausführen bleiben zwei getrennte Rollen.

Das wirkt zunächst wie eine kleine Stellschraube. Praktisch verschiebt sie aber, wo technische Entscheidungen entstehen, nämlich nicht mehr nur im Editor, sondern mitten im Teams-Kanal. Wenn Sie und Ihr Team ohnehin viel in Teams statt in dedizierten Entwicklerwerkzeugen kommunizieren, sparen Sie sich damit einen Tool-Wechsel für den ersten Schritt. Für Organisationen, die Teams als zentrale Kommunikationsplattform nutzen, verschiebt sich damit ein Stück der Entwicklungsarbeit an einen Ort, an dem vorher nur über Probleme gesprochen, aber nicht direkt daran gearbeitet wurde.

Bislang lief ein vergleichbarer Auftrag oft über Umwege: Screenshot aus dem Chat, Ticket im Tracker, Rückfrage an einen Entwickler. Jede dieser Stationen kostet Zeit und Kontext. Die Mention ersetzt diese Kette durch einen einzigen Schritt mitten im laufenden Gespräch.

Bemerkenswert ist, dass GitHub die Rollentrennung technisch und nicht nur organisatorisch durchsetzt. Eine Produktmanagerin ohne Schreibrechte kann eine Untersuchung anstoßen und beobachten, aber keinen Code verändern lassen. Erst wer im Repository tatsächlich schreiben darf, löst die eigentliche Änderung aus, ganz gleich, ob der Auftrag aus dem Chat oder aus der IDE kommt.

Der Standup wird zum Auftrag, bevor er zu Ende ist

GitHub nennt ein konkretes Szenario: Entsteht in einem Meeting ein Action Item, geben Sie es noch während der Diskussion oder kurz vor Ende im Meeting-Chat an Copilot weiter. Ein Team bespricht im Standup ein Problem, bittet Copilot parallel um eine Untersuchung, und der Agent beginnt mit der Lösung, bevor das Meeting endet.

Alle im Kanal sehen laut GitHub dieselbe Untersuchung und können sie bei Bedarf weiter steuern. Es gibt keinen separaten Copilot-Tab, den nur eine Person offen hat. Der Fortschritt liegt sichtbar im geteilten Thread, samt der Zwischenschritte, die der Agent dokumentiert.

Wie zuverlässig Copilot in einer lauten Standup-Situation den richtigen Kontext aus mehreren gleichzeitigen Wortmeldungen herausfiltert, verrät der Changelog-Text nicht. Das lässt sich nur im echten Einsatz beurteilen. Formulieren Sie den Auftrag im Meeting unscharf, bekommen Sie vermutlich auch eine unscharfe erste Analyse zurück.

Für tägliche Standups mit knapper Zeit ist genau das der eigentliche Gewinn: Die Untersuchung läuft parallel zum Gespräch statt danach als weitere Aufgabe auf der Liste zu landen. Bis zum nächsten Standup liegt im besten Fall bereits ein erster Lösungsvorschlag vor, über den sich diskutieren lässt.

Cloud-Sandbox erledigt die Arbeit, IDE und Terminal übernehmen den Rest

Ein aus Teams gestarteter Auftrag läuft laut GitHub asynchron in einer gesicherten Cloud-Sandbox weiter, während das Team im Kanal-Thread den Fortschritt verfolgt. Copilot muss dafür nicht in Echtzeit im Chat bleiben. Die eigentliche Ausführung passiert im Hintergrund, entkoppelt vom Gesprächstempo.

Sobald der Agent fertig ist, wandert die Arbeit weiter. GitHub verweist darauf, dass Sie die erzeugten Artefakte anschließend im Terminal, in der GitHub-Copilot-App oder in Ihrer bevorzugten IDE weiterbearbeiten können. Details zum Sandbox-Modell liefert die Dokumentation zu Cloud-Sandboxing.

Für Entwicklerinnen und Entwickler, die bereits mit Coding-Agents arbeiten, ist dieser Bruch vertraut: Der Chat liefert den Auftrag, die Feinarbeit, also Debuggen, Tests nachziehen und Commits sortieren, bleibt lokal. Die Sandbox übernimmt nur den ersten, oft mechanischen Teil. Wie GitHub im Changelog schreibt, sollen sich die Artefakte nahtlos zwischen Terminal, Copilot-App und IDE weiterbearbeiten lassen, was voraussetzt, dass alle drei Werkzeuge auf denselben Sandbox-Stand zugreifen.

Interessant ist die Reihenfolge. Teams startet, die Sandbox führt aus, die IDE übernimmt die Feinarbeit. Diese Kette funktioniert nur, wenn alle drei Umgebungen denselben Auftragsstand kennen; haben Sie die App nicht installiert oder das Terminal nicht mit dem Repository verbunden, verlieren Sie genau an dieser Nahtstelle Zeit.

Ob die Teams-Integration im Alltag tatsächlich Arbeit abnimmt oder nur eine weitere Übergabe erzeugt, zeigt sich an genau dieser Kette. Ein Auftrag, der in der Sandbox sauber durchläuft, spart Zeit. Ein Auftrag, der im Terminal erst neu zusammengesucht werden muss, kostet am Ende womöglich mehr, als die anfängliche Mention eingespart hat.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptIn an evening remote-work nook, two engineers and a compliance reviewer route an unmarked code folder through an extra approval tray before a sealed release box. A documentary composition emphasizes practical consequences; every surface is blank and unbranded, with no readable text, words, numbers, labels, logos, screens, user interfaces, dashboards, or signs. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Pull Requests erhalten eine Integrationsidentität

Der eigentliche Kontrollmechanismus sitzt am anderen Ende der Kette, beim fertigen Pull Request. Repository-Administratoren können jetzt laut GitHub für jeden Pull Request, der der Microsoft-Teams-Copilot-Integrationsidentität zugeschrieben wird, eine zusätzliche Freigabe verlangen, bevor gemerged werden darf.

Die Rechnung ist einfach und für Reviewer spürbar zugleich: Schreiben Sie in einem Repository bereits zwei Freigaben vor, brauchen Sie mit aktivierter Regel künftig drei Freigaben für alle Pull Requests, die Copilot aus einer Teams-Sitzung erzeugt hat.

GitHub begründet den Schritt damit, dass eine zusätzliche Freigabe einen Menschen im Loop hält, bevor agentisch erzeugte Arbeit tatsächlich ausgeliefert wird. Das Team soll dadurch nicht langsamer werden, aber die Kontrolle behalten, so die Lesart des Anbieters.

Ob drei Reviewer tatsächlich sorgfältiger prüfen als zwei, bleibt offen. Die Regel schafft immerhin einen klaren, technisch erzwungenen Prüfpunkt, den es vorher für Copilot-Teams-Pull-Requests schlicht nicht gab.

Die Integrationsidentität selbst ist dabei der eigentliche Kniff: GitHub unterscheidet technisch zwischen einem Pull Request, den ein Mensch direkt öffnet, und einem, der aus einer Teams-Agentensitzung stammt. Erst diese Unterscheidung erlaubt es, die zusätzliche Freigabe gezielt nur für Agenten-Arbeit zu erzwingen, statt pauschal jeden Pull Request zu verlangsamen.

Erst der Admin-Schalter, dann die Teams-App-Installation

Bevor Ihr Team überhaupt @GitHub tippen kann, muss eine Administratorin oder ein Administrator in Organisation oder Enterprise den Copilot-Cloud-Agent samt Cloud-Sandboxes freischalten. GitHub weist ausdrücklich darauf hin, dass Sandbox-Richtlinien dieselbe Konfiguration wie die Cloud-Agent-Richtlinien teilen, ein Schalter für zwei Funktionen.

Danach folgt die eigentliche Installation: Die GitHub-App für Microsoft Teams muss ins Team geholt werden. Anschließend genügt eine Mention von @GitHub, um den Prompts zur Verknüpfung Ihres GitHub-Kontos zu folgen.

Für öffentliche Kanäle lässt sich bei Bedarf ein Standard-Repository konfigurieren. Direktnachrichten kommen laut GitHub ohne ein solches Standard-Repository aus, dort geben Sie den Bezug bei jedem Auftrag neu mit. Kennen Sie die verfügbaren Befehle nicht auswendig, tippen Sie einfach @GitHub help.

Fünf Schritte insgesamt, vom Admin-Schalter bis zur ersten Mention. Das ist überschaubar, verlangt aber Abstimmung zwischen IT-Administration und den einzelnen Teams, weil die Freischaltung zentral erfolgt, die Installation aber pro Kanal oder Workspace erneut ansteht. Größere Organisationen mit mehreren Teams-Workspaces sollten diesen Rollout deshalb koordinieren, statt jedes Team einzeln experimentieren zu lassen.

Wer zahlt: AI-Credits und getrennte Sandbox-Budgets

Kostenlos ist der Zugang nicht. Die öffentliche Vorschau steht laut GitHub ausschließlich zahlenden Copilot-Plänen offen, und jede in Microsoft Teams gestartete Cloud-Agent-Sitzung verbraucht AI-Credits.

Für Organisationen greifen dabei die üblichen Mechanismen: Der Verbrauch von Cloud-Agent-AI-Credits unterliegt laut GitHub den nutzungsbasierten Budgets für Organisationen und Enterprises. Die Cloud-Sandbox-Nutzung wird separat abgerechnet und lässt sich über ein Produkt- oder SKU-Budget deckeln.

Zwei getrennte Budget-Töpfe für ein und denselben Auftrag: Klären Sie das vor dem Rollout, nicht danach. Wer nur das Copilot-Abo im Blick hat, übersieht sonst die separate Sandbox-Rechnung.

Je häufiger ein Team Aufträge direkt aus dem Meeting heraus startet, desto schneller summieren sich beide Posten. Ein kurzer Test mit klar begrenztem Budget vor dem teamweiten Rollout zeigt zuverlässiger, wie hoch der reale Verbrauch ausfällt, als jede Schätzung vorab.

Verwalten Sie Copilot-Budgets für IDE-Nutzung und Cloud-Agent-Aufträge bereits getrennt, können Sie die Teams-Sitzungen in dieselbe Struktur einhängen. Neu hinzu kommt lediglich, dass jetzt auch Meeting-Aufrufe unmittelbar Credits auslösen, nicht erst der spätere bewusste Agenten-Aufruf im Editor.

Was Teams jetzt vor der Umstellung klären sollten

Vor dem ersten produktiven Einsatz lohnt ein Blick auf die vollständige Setup-Anleitung für die Integration von Copilot Cloud Agent mit Microsoft Teams. Dort stehen Berechtigungen, Repository- und Branch-Auswahl sowie unterstützte Workflows im Detail, die der Changelog-Eintrag nur zusammenfasst.

Zwei Punkte verdienen vor dem Rollout besondere Aufmerksamkeit: Gleichen Sie die Freigaberegel für Teams-Pull-Requests mit Ihren bestehenden Branch-Protection-Regeln ab, und benennen Sie bei vielen Direktnachrichten-Aufträgen jedes Mal das Ziel-Repository korrekt, weil dort kein Standard-Repository greift. Wer beide Punkte vor dem ersten produktiven Einsatz klärt, vermeidet, dass ein Pull Request wegen einer falsch zugeordneten Freigaberegel unnötig im Review stecken bleibt.

Setzen Sie Copilot ohnehin schon als Cloud-Agent oder über Copilot Extensions ein, bekommen Sie mit der Teams-Anbindung einen weiteren Kanal, der in dieselben Governance-Fragen hineinspielt: Wer darf freigeben, wer darf auslösen, und wie viel darf ein Agent kosten, bevor jemand genauer hinsieht.

Ein sinnvoller erster Schritt ist ein einzelnes Pilot-Repository mit aktivierter Zusatzfreigabe, in dem ein kleines Team einige Wochen lang echte Aufträge aus Teams heraus stellt. Erst danach lässt sich beurteilen, ob drei Freigaben pro Pull Request den Merge-Durchsatz spürbar bremsen.

Auch die Kombination mit einer bestehenden Cloud-Agent-Anbindung an Projektmanagement-Tools wie Linear lohnt eine kurze Prüfung. Treffen Aufträge künftig aus drei Richtungen gleichzeitig ein, aus Meeting, Chat und Ticket, sollte vorab klar sein, welche Quelle im Zweifel Vorrang hat.