Copilot lässt ein Prüfmodell über Terminalbefehle entscheiden

Sie dürfen Copilot Terminalbefehle ohne Nachfrage ausführen lassen, sofern ein Prüfmodell sie als eindeutig sicher einstuft – aber nur dann. Seit dem 26. Oktober 2026 sind die Assisted Permissions in Copilot CLI, der Copilot-App und VS Code allgemein verfügbar: Ein Sprachmodell bewertet Befehle, Dateipfade und URLs, und Anfragen, die es als „clearly safe“ einstuft, laufen automatisch. Bestehende Deny-Regeln und Enterprise-Vorgaben bleiben in Kraft. GitHub warnt in der eigenen Dokumentation ausdrücklich, das Modell könne Fehler machen und gefährliche Aktionen freigeben. Wer die Funktion einschaltet, tauscht also einen Teil der Klicks gegen ein Urteil, zu dem GitHub keine Fehlerrate nennt.

Ein Modell liest mit, bevor der Befehl läuft

GitHub beschreibt Assisted Permissions in der Dokumentation unter „Allowing safe commands“ als Mittelweg zwischen manueller Freigabe und einer pauschalen Allow-All-Option. Ein großes Sprachmodell prüft Berechtigungsanfragen und gibt automatisch frei, was es im Kontext Ihrer Aufgabe für sicher hält. Damit gibt es drei Stufen: manuelle Freigabe, Assisted Permissions und unbedingte Freigabe. Letztere schalten Sie in der Copilot CLI mit –allow-all (oder –yolo) beziehungsweise mit /permissions allow-all (oder /yolo) ein.

Das Modell entscheidet allerdings nicht als Erstes. Nach der GitHub-Dokumentation werden bestehende Regeln und menschliche Freigaben vor der Modellprüfung ausgewertet. Was Ihre Berechtigungen ohnehin erlauben, läuft ohne Rückfrage und ohne Modellprüfung. Eine großzügige Allow-Regel in Ihrer Konfiguration umgeht die Prüfung daher vollständig. Erst bei den übrigen Anfragen bewertet das Prüfmodell Befehl, Pfad oder URL.

Dabei gibt es drei mögliche Ausgänge. Hält das Modell eine Anfrage für sicher, wird sie automatisch freigegeben. Ist es nicht überzeugt, fragt Copilot Sie wie bei manueller Freigabe. Steht die Sicherheitsprüfung nicht zur Verfügung oder kann sie die Anfrage nicht bewerten, gilt die normale Rechtebehandlung der Sitzung. Als Maßstab nennt der GitHub-Changelog vom 26. Oktober „clearly safe“. Was im Einzelnen darunter fällt, legen weder Changelog noch Dokumentation offen.

Eine Reibungsstelle ist die Modellfrage. Copilot wählt das Prüfmodell selbst aus, und es kann sich von dem Modell unterscheiden, das Sie für die Sitzung gewählt haben. Ist das ausgewählte Prüfmodell nicht verfügbar, kann die Prüfung auf das aktive Sitzungsmodell ausweichen. Nutzen Sie einen eigenen Modellanbieter, prüft ebenfalls das aktive Sitzungsmodell. Das Urteil über einen Befehl kann also von einem anderen Modell stammen als der Befehl selbst.

Aktiviert wird der Modus je nach Oberfläche unterschiedlich. In VS Code öffnen Sie den Permissions-Picker und wählen „Assisted permissions“. In der interaktiven Copilot CLI schalten /permissions assisted und /permissions manual zwischen den Modi um, und /permissions show ist als weiterer Befehl dokumentiert.

Visual Studio Magazine berichtete am 27. Oktober in einem Beitrag von David Ramel über die Einführung und nennt dieselben Eckpunkte: Das Modell bewertet Anfragen, „clearly safe“ läuft automatisch, Administrationen können Modi einschränken. Das Prinzip kennt Copilot bereits aus Assisted Approvals in JetBrains-IDEs. Neu ist die allgemeine Verfügbarkeit in CLI, App und VS Code.

Wo die Dokumentation Grenzen zieht

Die GitHub-Dokumentation zieht die Grenzen früh. Bestehende Deny-Regeln und Enterprise-Beschränkungen gelten weiter. Was Sie oder Ihre Organisation ausdrücklich verboten haben, wird nicht dadurch erlaubt, dass ein Modell es für harmlos hält. Das Prüfmodell sitzt hinter den Regeln, nicht über ihnen.

Zur Verlässlichkeit schreibt GitHub selbst: „The model can make mistakes and approve dangerous or unintended actions. This feature is not a substitute for sandboxing or access restrictions.“ Sinngemäß: Das Modell kann sich irren und gefährliche oder unbeabsichtigte Aktionen freigeben, und die Funktion ersetzt weder Sandboxing noch Zugriffsbeschränkungen. Fehlerraten oder Kriterien für die Einstufung „clearly safe“ nennen weder Changelog noch Dokumentation. Das heißt nicht, dass das Modell oft danebenliegt. Es heißt nur, dass sich das Risiko anhand der veröffentlichten Angaben nicht beziffern lässt.

Das Wort „unintended“ verdient Beachtung. dm-Einordnung: Ein Befehl kann zur Aufgabe passen und trotzdem nicht das sein, was Sie wollten. Eine solche Abweichung ist für ein Prüfmodell schwerer zu erkennen als ein offensichtlich zerstörerischer Befehl.

Sandboxing bedeutet, Befehle in einer abgeschotteten Umgebung auszuführen, damit ein Fehlgriff nur begrenzten Schaden anrichtet. Für Copilot gibt es dafür eine lokale Sandbox, und Assisted Permissions ersetzen sie nicht. Anfragen, das lokale Sandboxing zu umgehen, nimmt die Modellprüfung laut Dokumentation gar nicht erst in die Bewertung auf.

Für Cloud-Sessions hält die GitHub-Dokumentation fest: „Tool permission controls are not available for cloud sessions.“ (Die Steuerung von Tool-Berechtigungen ist dort nicht verfügbar.) dm-Einordnung: Assisted Permissions lassen sich dort demnach nicht einschalten, und wer dort Agenten laufen lässt, muss sich auf andere Schutzmaßnahmen stützen.

In der Copilot CLI gibt es eine Besonderheit bei Enterprise-Vorgaben. Verlangt eine Enterprise-ask-Regel für Shell-Befehle, das Lesen oder Schreiben von Dateien oder für URLs eine Rückfrage, kann eine Modellfreigabe diese Regel erfüllen, sofern die Anfrage prüfbar ist. Enterprise-deny-Regeln bleiben davon unberührt. Andere Tool-Calls, die Enterprise-Regeln freigabepflichtig machen, prüft das Modell nicht, dort bleibt es bei der Rückfrage.

Nicht-interaktive Läufe und CI

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptTwo software engineers reviewing code on a large monitor in a bright office, one pointing at an abstract highlighted command block, coffee mugs on the desk. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Als nicht-interaktiv gilt ein Lauf mit -p beziehungsweise --prompt oder ohne Terminal, etwa in CI/CD. Dort kann niemand eine Rückfrage beantworten, deshalb braucht es eine eigene Regelung. Sie aktivieren Assisted Permissions mit der Option --assisted-approval oder mit der Umgebungsvariable COPILOT_ASSISTED_APPROVAL auf true. Starten Sie die CLI damit interaktiv, beendet sie sich mit einem Fehler.

Im nicht-interaktiven Betrieb gilt eine klare Abfolge. Was das Prüfmodell nicht freigibt, wird abgelehnt, und die Begründung geht an Copilot zurück, damit es einen anderen Weg versucht. Andere freigabepflichtige Anfragen lehnt die CLI ebenfalls ab. Im Autopilot-Modus gilt dasselbe.

Ohne die Option wird alles Freigabepflichtige abgelehnt. Wer stattdessen --allow-all-tools setzt, gibt pauschale Rechte ohne jede Prüfung. Assisted Permissions liegen in diesem Betrieb also zwischen zwei Extremen: weder alles verweigern noch alles erlauben.

Eine Warnung steht in der GitHub-Dokumentation: --assisted-approval hat Vorrang vor --allow-all-tools, beschränkt aber --allow-all-paths und --allow-all-urls nicht. Kombinieren Sie die Option mit --allow-all, bleibt der Zugriff auf Pfade und URLs unbeschränkt. Die Modellprüfung greift dann nur bei Tool-Anfragen, nicht bei dem, was die Pfad- und URL-Rechte ohnehin erlauben.

Heikel ist der Fall, dass sich Assisted gar nicht einschalten lässt, etwa wegen Enterprise-Einstellungen. Die CLI schreibt dann lediglich eine Warnung auf Standard Error. Ein zusätzlich angegebenes --allow-all-tools bleibt wirksam, Tool-Anfragen laufen in diesem Fall ohne Prüfung.

dm-Einordnung: Ein Lauf, der trotz fehlgeschlagener Aktivierung weiterläuft, fällt in der Pipeline nicht durch einen Abbruch auf. Prüfen Sie die Logs automatisierter Läufe deshalb gezielt auf diese Warnung, besonders wenn --allow-all-tools gesetzt ist.

Was Administrationen abschalten können

Für Organisationen gibt es in den Enterprise-managed settings zwei getrennte Schalter. Mit permissions.disableBypassPermissionsMode: "disable" sperren Sie die unbedingte Freigabe. In der CLI betrifft das --allow-all und --yolo sowie /permissions allow-all und /yolo. Assisted Permissions bleiben dabei verfügbar.

Wollen Sie auch den Mittelweg unterbinden, setzen Sie permissions.disableAssistedPermissionsMode: true. Damit ist Assisted abgeschaltet, und es bleibt die manuelle Freigabe. Die beiden Schalter wirken unabhängig voneinander, Sie können also nur eine Stufe oder beide sperren.

Auch den Standardmodus legen Administrationen fest, und zwar über permissions.defaultMode. Dieser verwaltete Standard hat Vorrang vor der Nutzereinstellung defaultPermissionMode in ~/.copilot/settings.json. Dort sind die Werte „assisted“ oder „manual“ möglich, und die Einstellung gilt nur für neue interaktive Sessions.

Entwickelnde sind an den Standard nicht starr gebunden. Laut Dokumentation können sie einen anderen Modus wählen, sofern die Richtlinie ihn erlaubt, etwa mit /permissions manual. Ist der Standard nicht verfügbar oder verboten, startet die Session mit manueller Freigabe. Fortgesetzte Sessions behalten ihren gespeicherten Modus, vorbehaltlich der aktuellen Richtlinien.

Welcher Modus gerade aktiv ist, zeigt /permissions show. Das bietet sich als erste Kontrolle an (dm-Einordnung), wenn eine Session sich anders verhält als erwartet, etwa nach dem Fortsetzen einer älteren Sitzung.

Für die Richtlinienplanung heißt das: Administrationen, die sich bei Shell-Befehlen auf Enterprise-ask-Regeln als menschliche Bestätigung verlassen, müssen Assisted daher mit permissions.disableAssistedPermissionsMode: true abschalten. Das ist eine dm-Einordnung aus der dokumentierten Wirkungsweise, keine ausdrückliche Empfehlung von GitHub.