Copilot CLI von GitHub: Installation, erste Aufgaben und Kosten

Copilot CLI installieren und anmelden

GitHubs stabiles npm-Paket heißt @github/copilot und setzt Node.js 22 oder neuer voraus. Unter Windows ist zusätzlich PowerShell v6 oder höher erforderlich. Stellt eine Organisation Copilot bereit, muss die Administration die Richtlinie für Copilot CLI aktivieren. Installationsvoraussetzungen.

Die Installation erfolgt mit diesem Terminalbefehl:

npm install -g @github/copilot

Steht in der ~/.npmrc die Einstellung ignore-scripts=true, nennt GitHub diese Alternative: npm_config_ignore_scripts=false npm install -g @github/copilot. Weitere dokumentierte Installationswege sind winget install GitHub.Copilot unter Windows, brew install --cask copilot-cli unter macOS oder Linux sowie curl -fsSL https://gh.io/copilot-install | bash unter macOS oder Linux. Die Voraussetzung für Node.js gilt für die Installation über npm. Installationsbefehle von GitHub.

Zum Start in das gewünschte Repository wechseln und copilot eingeben. Anschließend bestätigen, dass der Ordner vertrauenswürdig ist — für die aktuelle oder auch für künftige Sitzungen. Falls noch keine Anmeldung vorliegt, bei der entsprechenden Aufforderung /login innerhalb von Copilot eingeben. Erster Start.

Als Ziel dient GitHub.com oder der Hostname der GitHub-Enterprise-Cloud-Instanz mit Datenresidenz. Auf einem lokalen Desktop bietet sich die Anmeldung im Browser an; entfernte Umgebungen oder solche ohne grafische Oberfläche bieten normalerweise zuerst den Gerätecode-Ablauf an. Im Browser die Autorisierung abschließen, gegebenenfalls Organisationen mit SAML SSO autorisieren und der Anwendung GitHub Copilot CLI Zugriff gewähren. Nach der Anmeldung geht es zurück ins Terminal. Die Authentifizierung lässt sich auch aus der Shell mit copilot login starten. Anmeldung und Authentifizierung.

Verwendet die CLI das falsche Konto, sollten die vorhandenen Variablen COPILOT_GITHUB_TOKEN, GH_TOKEN und GITHUB_TOKEN geprüft werden: Explizit exportierte Tokens haben Vorrang vor der gespeicherten Anmeldung. Für die Automatisierung unterstützt GitHub ein Token mit fein abgestuften Berechtigungen für ein persönliches Konto; erforderlich ist dabei die Kontoberechtigung Copilot Requests. Klassische Personal Access Tokens werden nicht unterstützt. Authentifizierung und Token-Priorität.

Erste Aufgaben: Repository verstehen, Tests reparieren, PR öffnen

Am Anfang steht eine Frage, danach eine überprüfbare Änderung und schließlich ein Pull Request. Die CLI lässt sich wie ein Entwickler am gemeinsamen Arbeitsplatz verstehen: Sie untersucht das Projekt und bedient Werkzeuge; welche Aktionen erlaubt sind, bleibt eine bewusste Entscheidung.

Die Tabelle unterscheidet Shell-Befehle von Eingaben innerhalb einer interaktiven copilot-Sitzung. Sämtliche aufgeführten Befehle und Prompts stammen aus GitHubs Dokumentation. Jede Modellinteraktion verbraucht KI-Credits; einen festen Credit-Preis für diese Aufgaben veröffentlicht GitHub nicht. Abrechnung der CLI-Nutzung.

Erst das Repository verstehen, dann den Code ändern

Beim Einstieg in ein unbekanntes Projekt bietet sich der Erklärungsbefehl aus der Tabelle an. GitHubs Beispiel wählt Claude Haiku 4.5: -p übergibt einen einzelnen Prompt und beendet anschließend den Aufruf, -s unterdrückt zusätzliche Ausgabe, und --model wählt das Modell. Ist dieses Modell im jeweiligen Tarif oder aufgrund einer Richtlinie nicht verfügbar, lässt sich in einer interaktiven Sitzung mit /model eine verfügbare Option auswählen. Die Konten Free und Student verwenden die Auswahl Auto. Beispiel für den programmatischen Aufruf, Modellzugriff.

Die Erklärung hilft, Einstiegspunkte und Testkonfiguration zu finden. Anschließend sollten die genannten Dateien selbst geprüft werden. So entsteht eine konkrete Orientierung, die sich hinterfragen lässt, statt einer weiteren unstrukturierten Suche durch Verzeichnisse.

Einen fehlgeschlagenen Test mit klarem Ziel reparieren

Bei einem defekten Test kann ein Maintainer zunächst den tatsächlichen Testbefehl des Repositorys ausführen, Copilot die Fehlerausgabe geben und anschließend den interaktiven Prompt aus der Tabelle verwenden. GitHub führt diese Formulierung im Ablauf für testgetriebene Entwicklung auf, nachdem fehlgeschlagene Tests erstellt und geprüft wurden. Bei einem bestehenden Fehler braucht Copilot denselben Kontext: Welcher Test schlägt fehl, und welches Verhalten soll erhalten bleiben? Vor der Übernahme der Änderung den Diff prüfen und den betreffenden Test erneut ausführen. GitHubs Testablauf.

Für einen Test, der bereits in der CI fehlschlägt — also in den automatisierten Prüfungen eines bestehenden Pull Requests — nennt GitHub /pr fix ci focus on test failures. Der Befehl untersucht Logs, nimmt Korrekturen vor und kann Änderungen pushen. Damit ist er ein anderer Arbeitsablauf als die Reparatur eines lokalen Tests. Für den aktuellen Branch muss bereits ein PR existieren. CI-Fehler beheben.

Nach der Prüfung einen Pull Request öffnen

Wer als Gründer eine kleine Korrektur ausliefern möchte, kann nach Prüfung und Commit der Änderung vom Arbeitsbranch aus /pr create verwenden. Voraussetzung ist ein Git-Repository, das auf GitHub liegt. Copilot pusht lokale Commits und erstellt den PR; Titel und Beschreibung richten sich nach der PR-Vorlage des Repositorys. Existiert für den Branch bereits ein PR, wird dieser aktualisiert. Pull Request erstellen.

Das Ergebnis ist eine überprüfbare Übergabe im bestehenden GitHub-Ablauf des Teams. Die Verantwortung für den Inhalt des Branches bleibt bestehen.

Welche Freigaben verlangt Copilot vor der Ausführung?

Ordnervertrauen und Werkzeugberechtigungen sind getrennte Entscheidungen. Benötigt eine Aktion eine Freigabe, lässt sie sich einmalig erlauben, das Werkzeug für die laufende Sitzung freigeben oder die Aktion mit einer Rückmeldung ablehnen. Eine Sitzungsfreigabe gilt für das Werkzeug samt seinen Optionen. Freigabeabfragen.

Reine Lesezugriffe können automatisch erfolgen. Potenziell destruktive Aktionen, Schreibzugriffe und URL-Aufrufe benötigen eine Freigabe, sofern diese noch nicht erteilt wurde. Manche Abfragen bieten eine gespeicherte Freigabe für das Repository oder Verzeichnis an. Dauerhaft freigegebene URL-Domains gelten auch in späteren Sitzungen. Gespeicherte Berechtigungen.

GitHub zeigt dieses Beispiel für vorab konfigurierte Berechtigungen:

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

Damit sind Git-Befehle erlaubt, Pushes jedoch gesperrt. Verbotsregeln haben Vorrang vor Erlaubnisregeln und gespeicherten Freigaben. /reset-allowed-tools löscht sowohl die Sitzungsfreigaben als auch gespeicherte Werkzeugfreigaben für den aktuellen Ort. Danach gelten wieder die beim Start festgelegten Berechtigungen. Erlaubnis- und Verbotsregeln.

--allow-all-tools gibt alle verfügbaren Werkzeuge frei. --allow-all oder --yolo erlauben zusätzlich sämtliche Pfade und URLs. GitHub empfiehlt, solche umfassenden Freigaben in einer isolierten Umgebung zu verwenden. Für die ersten Aufgaben empfiehlt sich der normale Ablauf mit Freigabeabfragen. Umfassende Berechtigungsoptionen.

In welchen Tarifen ist die CLI enthalten, und wie wird abgerechnet?

Alle Copilot-Tarife enthalten die CLI: Free, Student, Pro, Pro+, Max, Business und Enterprise. Für einen bestehenden Copilot-Zugang ist kein separates CLI-Abo nötig. Die folgende Tabelle zeigt die aktuellen monatlichen Preise und Kontingente von GitHubs Tarifseite. Copilot-Tarife.

Das Flex-Kontingent ist variabel. Die aktuellen Gesamtwerte sind daher keine dauerhafte Zusage für die verfügbare Kapazität. Ein KI-Credit entspricht $0.01 USD. Wie viel verbraucht wird, hängt von den Preisen des gewählten Modells sowie den Eingabe-, Ausgabe- und zwischengespeicherten Tokens ab. Chat und CLI greifen auf dasselbe Kontingent zu. Codevervollständigungen und Vorschläge für die nächste Änderung bleiben in kostenpflichtigen Tarifen unbegrenzt und verbrauchen keine KI-Credits. Abrechnung für Einzelpersonen.

Bei einem bestehenden Pro-Abo bleibt der Abopreis bei $10 monatlich. Die Modellarbeit im Terminal teilt sich das aktuelle Kontingent von 1,500 Credits mit anderen Aufgaben. Für die wirtschaftliche Entscheidung heißt das: erst den bereits bezahlten Zugang ausprobieren und dann prüfen, ob das gemeinsame Kontingent zum Arbeitsumfang passt. Einzelpersonen mit einem kostenpflichtigen Tarif können ein Budget für zusätzliche Nutzung festlegen, in einen höheren Tarif wechseln oder auf die monatliche Rücksetzung warten. Die öffentliche Preistabelle bietet im Tarif Free keinen Kauf zusätzlicher Credits an. Kontingente für Einzelpersonen, Kaufbeschränkungen im Tarif Free.

Bei Business und Enterprise werden die Credits auf Ebene der Abrechnungseinheit zusammengeführt. Zusätzliche kostenpflichtige Nutzung ist standardmäßig aktiviert und lässt sich administrativ deaktivieren. Ein Nutzerbudget oder eine Ausgabenobergrenze des Unternehmens kann den Zugriff stoppen, selbst wenn ein anderes Kontingent noch nicht ausgeschöpft ist. Für eine korrekte Anzeige von Abrechnung und Nutzung empfiehlt GitHub CLI 1.0.48 oder neuer. Abrechnung für Organisationen.

Nach einer Aufgabe zeigt /usage die Credits der Sitzung und den Tokenverbrauch der Modelle an. In einer interaktiven Sitzung lässt sich mit /limits set max-ai-credits NUMBER eine Grenze setzen; NUMBER wird durch das gewünschte Kontingent ersetzt. Das Minimum beträgt 30 Credits. Die Funktion befindet sich in der öffentlichen Vorschau und setzt eine weiche Grenze: Eine bereits laufende Antwort wird abgeschlossen und kann das Limit leicht überschreiten. Nutzungsanzeige, Sitzungslimits.

Welche Modelle unterstützt Copilot CLI?

/model zeigt innerhalb von Copilot die verfügbaren Optionen an; für einen Shell-Aufruf dient --model. GitHubs aktuelle Übersicht der Clients führt die folgenden Modelle als CLI-kompatibel auf. Der Tarif und die Richtlinien der Administration können den Zugriff einschränken. Unterstützte Modelle.

GitHubs separate CLI-Tabelle für Auto enthält außerdem GPT-6.1 Sol. Free und Student können ausschließlich Auto verwenden. Da sich die Verfügbarkeit ändert, ist die Modellauswahl im jeweiligen Konto für die aktuellen Optionen maßgeblich. Auto und Verfügbarkeit je Tarif.

Projektanweisungen und MCP-Werkzeuge einrichten

Die Arbeitsregeln des Repositorys gehören vor wiederkehrenden Änderungsaufträgen in die Konfiguration. Benutzerdefinierte Anweisungen sind Markdown-Dateien, die Copilot als Kontext einliest. Projektweite Build- und Testbefehle sowie Konventionen gehören in .github/copilot-instructions.md. Für Regeln zu bestimmten Pfaden dienen .github/instructions/**/*.instructions.md mit applyTo-Mustern. Benutzerdefinierte Anweisungen.

Die CLI erkennt außerdem AGENTS.md, CLAUDE.md, .claude/CLAUDE.md und GEMINI.md. Nutzerweite Einstellungen können in ~/.copilot/copilot-instructions.md oder ~/.copilot/instructions/**/*.instructions.md liegen. Anwendbare Anweisungen werden kombiniert; GitHub legt keine allgemeine Rangfolge zwischen ihnen fest. Sie sollten deshalb widerspruchsfrei bleiben. Mit /instructions lassen sich erkannte Dateien prüfen oder deaktivieren. Erkennung und Zusammenspiel von Anweisungen.

MCP, Model Context Protocol, verbindet einen Agenten mit externen Werkzeugen und Daten. Damit kommt am gemeinsamen Arbeitsplatz eine Verbindung zu einem weiteren Dienst hinzu. Der GitHub MCP Server ist bereits integriert. Weitere Server lassen sich mit /mcp add hinzufügen; Tab wechselt zwischen den Feldern, Ctrl+S speichert. Lokale oder stdio-Server starten einen Prozess, HTTP-Server verbinden sich mit einem entfernten Endpunkt. Auch das ältere SSE-Verfahren wird unterstützt. MCP-Server hinzufügen.

GitHubs Terminalbeispiel lautet copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp. Die Nutzerkonfiguration liegt in ~/.copilot/mcp-config.json; für die Projektkonfiguration kommen .mcp.json oder .github/mcp.json infrage. Laut dem speziellen MCP-Leitfaden gelten konfigurierte Richtlinien für das Organisationsregister und die Freigabeliste auch für die CLI. Terminalbeispiel, Konfiguration und Richtlinien.

Wann eignen sich CLI, IDE oder ein anderer Agent?

Meine Empfehlung: Mit Copilot CLI beginnen, wenn die Aufgabe ohnehin im Terminal liegt und bereits ein Copilot-Zugang vorhanden ist. Die IDE-Erweiterung eignet sich, wenn die Arbeit direkt an der bearbeiteten Datei stattfinden soll, Änderungen visuell geprüft werden sollen und der Editor die zentrale Arbeitsumgebung bleiben soll. Unser Vergleich von Cursor und GitHub Copilot hilft bei dieser Entscheidung.

Über die ersten Aufgaben hinaus bieten sich diese Einsatzmöglichkeiten an:

• Ein Maintainer, der ein Review vorbereitet, könnte ein Code-Review des Arbeitsbranches anfordern, die Befunde untersuchen und den Diff anschließend an einen menschlichen Reviewer weitergeben. So entsteht eine gezielte Prüfliste, sofern die Befunde der Überprüfung standhalten. GitHub dokumentiert lokale Review-Abläufe. Hinweise zur Review-Unterstützung.
• Ein Entwickler, der PR-Feedback bearbeitet, könnte /pr fix feedback verwenden, die vorgeschlagenen Änderungen prüfen und die daraus folgenden Pushes freigeben. So bleiben Änderungswünsche und Diskussion zusammen. Der Befehl kann auf bearbeitete Review-Threads antworten und sie als erledigt markieren; vor der Freigabe sollte deshalb sein Umfang geprüft werden. Feedback bearbeiten.

Ein anderer Terminalagent kommt infrage, wenn ein anderes Abokontingent, eine andere Anbieterkonstellation oder mehr Kontrolle über den Agenten selbst benötigt wird. Für diese Kaufentscheidung hilft unser Vergleich von Claude-Code-Alternativen und Terminalkosten. Zunächst lohnt sich die Prüfung, ob Copilots eigene Modellauswahl die Anforderungen bereits erfüllt: GitHub dokumentiert auch die Einbindung eines eigenen Anbieters, einschließlich kompatibler lokaler Modelle. Dafür ist eine separate Anbieterkonfiguration nötig; außerdem werden Tool Calling und Streaming vorausgesetzt. Dieser Weg erfordert eine andere Einrichtung als die Nutzung des Copilot-Kontingents. Eigene Modelle einbinden.

Was könnte ein kleines Team darauf aufbauen?

Ein Onboarding-Paket für Repositorys bietet den stärksten Einstieg. Entwickler suchen nach “how to understand a new codebase” und “ai tool to understand codebase.” Ein Team könnte Entwicklungsverantwortlichen ein gepflegtes Paket aus Architekturnotizen, geprüften Build-Anweisungen und klar abgegrenzten Onboarding-Aufgaben verkaufen. Die kleinste sinnvolle Version würde das Repository des Kunden abdecken und den Ablauf aus Erklärung, Test und PR vorführen. Der Haken: Allgemeine Prompts lassen sich leicht kopieren. Bezahlt würde für gepflegtes Projektwissen.

Auch ein Ablauf zur Review-Vorbereitung ist denkbar. Suchanfragen wie “ai code review tools” und “ai powered code review platform” zeigen den Bedarf. Ein Team könnte Projektanweisungen und eingebundenen Issue-Kontext so bündeln, dass daraus ein Review-Paket mit Änderungen, Testnachweisen und offenen Fragen entsteht. Käufer wäre ein Teamleiter, der Übergaben vereinheitlichen möchte. Der Haken: Generierte Befunde müssen überprüft werden, und der Ablauf muss sich neben GitHubs bestehenden Review-Funktionen bewähren. Das sind mögliche Produktansätze, keine nachgewiesenen Ergebnisse.

Welche Grenzen gehören in die Planung?

Die CLI kann eine überzeugend wirkende Änderung erzeugen, die trotzdem falsch ist. GitHubs Hinweise zum verantwortungsvollen Einsatz warnen vor ungenauen oder unvollständigen Ausgaben und fordern dazu auf, Code und Befehle der CLI zu überprüfen. Die relevanten Tests müssen weiterhin bestehen, und der Diff muss geprüft werden. Verantwortungsvoller Einsatz.

Ein vertrauenswürdiger Ordner garantiert keine Isolation. GitHub beschreibt die Begrenzung von Verzeichnisberechtigungen als heuristisch und garantiert keinen Schutz sämtlicher Dateien außerhalb vertrauenswürdiger Verzeichnisse. Der Start sollte im Repository erfolgen, in dem gearbeitet werden soll. Für engere Beschränkungen aktiviert /sandbox enable die lokale Sandbox für Werkzeuge. GitHubs lokale und cloudbasierte Sandboxes befinden sich in der öffentlichen Vorschau. Verzeichnisvertrauen und Sandboxing.

Zugriffs- und Ausgabenlimits gelten weiterhin. Ein dokumentiertes Modell kann im jeweiligen Tarif fehlen oder per Richtlinie deaktiviert sein. Die CLI teilt sich Credits mit anderer Copilot-Nutzung, und das Sitzungslimit in der Vorschau kann leicht überschritten werden. Organisationsbudgets können die Nutzung stoppen, ohne automatisch auf ein günstigeres Modell umzuschalten. Modellzugriff, Sitzungslimits, Verhalten bei Budgetgrenzen.

Für die nächste Arbeitssitzung eignet sich ein tatsächlich fehlgeschlagener Test auf einem überprüfbaren Branch. Erst den relevanten Code erklären lassen, dann die Werkzeuganfragen für die Reparatur freigeben, den Test erneut ausführen, /usage prüfen und schließlich den PR öffnen. Damit lässt sich konkret beurteilen, wie gut der Ablauf zur eigenen Arbeit passt und wie hoch der Verbrauch ausfällt.

Für einen Repository-Ablauf, der auf die Prüfungen und angebundenen Werkzeuge des Teams abgestimmt ist: Wir entwickeln KI-Automatisierungen.