GitHub macht den Copilot-Code-Review über REST- und GraphQL-APIs verwaltbar und die Review-Übersicht kompakter: Unternehmens-, Organisations- und Repository-Einstellungen sind les- und änderbar, doch Unternehmens- und Organisationsendpunkte lehnen GitHub Apps und fein granulare Token ab, und maximale Intensität, Abrechnung und Genehmigungen bleiben außerhalb der API

Am 6. November 2026 veröffentlichte GitHub einen Changelog-Eintrag mit dem Titel Copilot code review: API management and review overview updates (Copilot-Code-Review: API-Verwaltung und Aktualisierungen der Review-Übersicht). Er sagt, dass sich Einstellungen für den Copilot-Code-Review nun über die REST- und GraphQL-APIs verwalten lassen, von der Unternehmensrichtlinie bis zu einzelnen Repositories, und dass der Übersichtskommentar, den Copilot an einem Pull Request hinterlässt, jetzt kompakter ist. Laut Eintrag sind die Neuerungen für die Tarife Copilot Pro, Pro+, Max, Business und Enterprise verfügbar. Er sagt nicht, ob ein Teil eine Vorschau ist, und nennt keine Preisänderung. Es ist ein Changelog des Anbieters, und wir haben die Endpunkte nicht getestet.

Schon vor dieser Änderung konnte man über die REST-API einen Review anfordern, die Review-Intensität wählen und Informationen zurücklesen. Der Eintrag fügt drei Dinge hinzu. Erstens kennzeichnen ausdrückliche Zuordnungsfelder die Reviews und Kommentare von Copilot. Zweitens zeigt eine Antwort die verwendete Review-Intensität, sofern diese Metadaten vorliegen. Drittens listet sie auf, welche Skills, MCP-Server und benutzerdefinierten Anweisungen Copilot als Quellen eines Kommentars gemeldet hat. Die Formulierung „gemeldet“ ist wichtig: Diese Felder beschreiben, was Copilot selbst als genutzt angibt, und der Eintrag behauptet keinen Weg, das zu überprüfen. Für Teams, die KI-Review-Kommentare prüfen, helfen diese Felder, die Ausgabe von Copilot von menschlichen Kommentaren zu trennen und zu sehen, was einen Befund geprägt hat.

Der Einstellungsteil folgt den drei Verwaltungsebenen von GitHub. Unternehmensadministratoren können den Code-Review für alle Organisationen aktivieren oder deaktivieren oder die Entscheidung den Organisationsadministratoren überlassen. Organisationsadministratoren können Aktivierung, Standard-Review-Intensität und Runner-Konfiguration verwalten, aber keine vom Unternehmen verwaltete Einstellung überschreiben. Repository-Administratoren können die Review-Intensität verwalten und ob Reviews benutzerdefinierte Anweisungen und MCP-Werkzeuge nutzen. Die REST-API akzeptiert dieselben Intensitätsstufen wie die Weboberfläche, und die Einstellungsantworten listen die für den Aufrufer verfügbaren Stufen auf. In der GitHub-Dokumentation heißen die Stufen Lite, ein Standard-Review, Balanced, das komplexe Logik, sicherheitsrelevanten Code und dienstübergreifende Änderungen tiefer prüft und die eingebaute Voreinstellung ist, und Max, das mehrere Modelle mit starkem Schlussfolgern für den intensivsten Review einsetzt.

Der Eintrag enthält eine leicht zu übersehende Warnung zur Authentifizierung. Die Endpunkte für Unternehmens- und Organisationseinstellungen, einschließlich des Organisations-Runner-Endpunkts, unterstützen weder GitHub Apps noch fein granulare persönliche Zugriffstoken. Die Endpunkte für Repository-Einstellungen unterstützen beides, mit der Berechtigung Administration lesen zum Lesen und Administration schreiben zum Ändern. Klassische persönliche Zugriffstoken benötigen Repository-Administratorzugriff. Eine als GitHub App gebaute Automatisierung kann also Repositories verwalten, aber keine Organisations- oder Unternehmensrichtlinien. Die Dokumentation sagt außerdem, dass andere Einstellungen der Konfigurationsseite, etwa maximale Review-Intensität, Abrechnung und Genehmigungen, nicht über die API verfügbar sind.

Auch der Übersichtskommentar des Reviews ändert sich. Neue Übersichten halten Befunde oben zusammen. Die verwendete Review-Intensität und eventuelle Umfragen wandern in eine kompakte Fußzeile. Übersprungene und aus inhaltlichen Gründen ausgeschlossene Dateien teilen sich einen Abschnitt namens Files not reviewed, mit Dateinamen und verlinkten Gründen. Leere Abschnitte entfallen, und lange Listen zeigen eine Überlaufzahl. Mit einem Daumen nach unten bei einer Übersicht kann man jetzt einen Grund hinzufügen, etwa eine Genehmigungsbewertung, der man nicht zustimmt, einen zu wortreichen Kommentar oder falsche oder kleinliche Befunde.

Weitere Verbesserungen: In Sitzungen des Copilot-Code-Review-Agenten werden die verbrauchten KI-Guthaben angezeigt; die Repository-Regel Automatically request Copilot code review unterstützt eine Umgehungsliste, sodass ausgenommene Akteure keinen automatischen Review erhalten; bei späteren Reviews desselben Pull Requests werden Befunde ohne Bezug zu den jüngsten Änderungen eingeklappt und dann ausgeblendet; und Reviews mit der Intensität Balanced nutzen jetzt drei Review-Modelle, wobei ein weiteres Modell deren Befunde zusammenführt. Fehlerbehebungen bewahren Abrechnungs- und Vorschaueinstellungen, wenn der Code-Review aus- und wieder eingeschaltet wird, wiederholen einen fehlgeschlagenen oder abgelaufenen Review einmal und wechseln zu einem anderen geeigneten Modell, wenn das bevorzugte nicht verfügbar ist, erlauben GitHub Actions, Dependabot und organisationseigenen Apps wieder, Reviews für von Bots erstellte Pull Requests anzufordern, wenn die Einstellung zum Blockieren von mit einer externen Copilot-Lizenz angeforderten Reviews aktiv ist und die Organisation zahlt, und beenden falsche Fehlermeldungen unmittelbar nach dem Start eines Reviews.

Die GitHub-Dokumentation ergänzt eine Regel zu automatischen Reviews. Ein Pull Request kann sich aus mehreren unabhängigen Quellen dafür qualifizieren, nämlich den eigenen Einstellungen des Nutzers, Repository-Regelsätzen und Organisations-Regelsätzen. Sie werden getrennt ausgewertet, Copilot veröffentlicht weiterhin nur einen Review, und die Einstellungen eines Nutzers können Push- oder Entwurfs-Reviews, die ein Regelsatz aktiviert hat, nicht abschalten.

Unsere Einordnung: Für Administratoren ist nützlich, dass Richtlinien zu Code werden können. Teams können Unternehmens-, Organisations- und Repository-Einstellungen nun per Skript verwalten und Kommentare zuordnen, statt sich durch Seiten zu klicken. Die Grenzen sind klar. Die Authentifizierungsregel verhindert GitHub-App-Automatisierung auf den oberen zwei Ebenen, wichtige Steuerungen bleiben außerhalb der API, die Quellenfelder meldet Copilot selbst, und der Eintrag nennt keine Zahlen zur Review-Qualität. Man sollte die Endpunkte zuerst an einem kleinen Repository testen.