Zum Hauptinhalt springen
Heißluftballon mit Entwickler und Roboter in der Gondel, am Boden zieht eine Person ein Halteseil am Pflock straff
Blog·

GitHub Copilot CLI im Unternehmen: was Admins vor dem Rollout festlegen

Copilot CLI im Unternehmen freigeben? Zusatznutzung ist standardmäßig an, Budgets stoppen nicht immer, das Audit-Log zeigt keine Sitzungen (Stand 09/2026).

Porträt von Antonio Agudo

Geschrieben von

Antonio Agudo

Inhouse-Enablement für Entwicklerteams · davor zwei Jahre KI in Produktion · Köln

Am 25. Februar 2026 hat GitHub die Copilot CLI für allgemein verfügbar erklärt. Die Regler, mit denen eine Organisation den Terminal-Agenten steuert, kamen später, die meisten in den vergangenen zwölf Wochen: die zentrale Vorgabedatei managed-settings.json am 1. Juli, ihre Auslieferung per MDM am 8. Juli, verbindliche Freigabelisten für MCP-Server am 6. August, Content Exclusion, also der Ausschluss gesperrter Dateien aus dem Kontext, am 2. September und zentral vorgegebene Rechte für Shell, Dateien und Domains am 9. September.

Wer die CLI im Frühjahr geprüft hat, hat ein anderes Produkt geprüft: ein Werkzeug ohne Content Exclusion, dessen Rechte für Shell und Dateien sich nur lokal festlegen ließen.

Die Regler für einen verantworteten Rollout gibt es inzwischen fast alle. Die Freischaltung allein legt den Betrieb aber nicht fest: Zusatznutzung ist standardmäßig an, Budgets oberhalb der Nutzerebene stoppen nur mit einer zusätzlichen Option. Bei Rechten und Audit muss die Organisation klären, welche Grenzen sie zentral durchsetzt und welche Handlungen sie später nachweisen kann.

Welcher Agent überhaupt ins Team passt, klärt der Leitfaden zur Werkzeugwahl für Coding-Agents-Teams.

Stand aller Angaben: 22. September 2026, Copilot CLI 1.0.87.

Was ist die Copilot CLI?

Die GitHub Copilot CLI ist GitHubs Coding-Agent für das Terminal, der Fragen beantwortet, Code schreibt und debuggt, Shell-Befehle ausführt und auf GitHub.com zugreift (GitHub-Doku). Sie läuft unter Linux, macOS und Windows.

Laut Microsoft nutzten im April 2026 knapp 140.000 Organisationen GitHub Copilot, und die Nutzung der CLI verdoppelte sich damals nahezu von Monat zu Monat.

Zu GitHub Copilot gehören der Agent Mode im Editor, der cloud agent (vormals coding agent) auf Basis von GitHub Actions und die CLI lokal im Terminal. Die alte Erweiterung gh copilot ist seit dem 25. Oktober 2025 abgeschaltet, der Befehl führt heute zur neuen CLI. „Microsoft Copilot CLI“ vermischt zwei Marken, und die gleichnamige AWS Copilot CLI ist ein eingestelltes Werkzeug für Container-Deployments.

Die Lizenz für GitHub Copilot reicht nicht: eine Policy schaltet die CLI frei

„All plans include Copilot CLI and Copilot app“, steht in GitHubs Planübersicht (Stand: 22. September 2026).

Bei Copilot Business und Enterprise muss ein Admin die CLI aber erst freischalten: „an administrator must enable Copilot CLI from the Policies page“, schrieb GitHub zum GA-Start.

Die Policy „Copilot CLI“ steht im Enterprise-Konto unter AI controls → Copilot → „Configure features & clients“, in der Organisation unter Settings → Copilot → Policies. „Enabled everywhere“ oder „Disabled everywhere“ auf Enterprise-Ebene gilt für alle Organisationen, erst „Let organizations decide“ überlässt ihnen die Wahl (Admin-Doku).

Tückisch wird es bei Nutzern mit Seats in mehreren Organisationen. Für die CLI-Policy gilt dann laut Doku zu Policy-Konflikten die freizügigste Einstellung. Sperrt die Stammorganisation die CLI und gibt eine Projektorganisation sie frei, nutzt dieselbe Person die CLI. Wer die CLI bis zur Entscheidung gesperrt lassen will, setzt die Policy auf Enterprise-Ebene auf „Disabled everywhere“.

Seit dem 27. Juli 2026 hat die Copilot app eine eigene Policy mit Standardwert „Enabled everywhere“. Der Changelog sagt dazu: „Disabling Copilot CLI does not disable the GitHub Copilot app.“ Admins legen beide Policies gemeinsam fest.

GitHub Copilot Business vs. Enterprise: die Trennlinie ist das Enterprise-Konto

Server-managed settings, der Tab AI controls, die Agenten-Felder im Audit-Log und Enterprise Custom Agents setzen ein Enterprise-Konto voraus, nicht den Plan Copilot Enterprise. Einen Governance-Regler, den nur dieser Plan freischaltet, nennt die Doku zum 22. September 2026 nicht.

Copilot-Business-Kunden ohne Enterprise-Konto können eine „Copilot Standalone“-Enterprise ohne Organisationen anlegen. Für server-managed settings brauchen sie trotzdem eine GitHub-Enterprise-Lizenz für die Organisation mit dem .github-private-Repo (Doku). Ob MDM- und dateibasierte Vorgaben ohne Enterprise-Konto greifen, beantworten die geprüften Quellen nicht (Stand: 22. September 2026).

Unterschiedlich ist dagegen das enthaltene Kontingent: 1.900 AI Credits pro Nutzer und Monat in Business, 3.900 in Enterprise (Abrechnungsdoku).

Copilot CLI installieren und aktualisieren auf verwalteten Geräten

Die Installationsdoku nennt npm (npm install -g @github/copilot, ab Node.js 22), WinGet, Homebrew, ein Installationsskript und Einzel-Binaries aus den Releases. Eine Anleitung für Intune, Jamf oder Offline-Installation enthält sie nicht (Stand: 22. September 2026). Pinnen lässt sich die Version über VERSION= im Skript, @version bei npm oder ein festes Binary.

Die CLI ändert sich schnell: 53 stabile Releases zwischen dem 17. April und dem 21. September 2026, also zwei bis drei pro Woche. Homebrew-, WinGet- und Skript-Installationen aktualisieren sich laut GA-Post selbst, autoUpdate steht standardmäßig auf true.

Mit --no-auto-update oder COPILOT_AUTO_UPDATE=false schaltet man automatische Updates ab. Zentral per managed settings lässt sich autoUpdate nicht setzen (Stand: 22. September 2026). Den Versionsstand aller Rechner friert man also über Umgebungsvariable oder Installationsweg ein.

Windows, Proxy und Anmeldung

Unter Windows läuft die Copilot CLI in PowerShell 7 und in WSL. Hinter einem Proxy liest sie proxyUrl, vorrangig aber HTTPS_PROXY. Kerberos unterstützt sie seit Version 1.0.62. Eine Token-Variable wie GH_TOKEN übersteuert laut Anmeldedoku stillschweigend die gespeicherte OAuth-Anmeldung.

GitHub Copilot AI Credits und Budgets: Zusatznutzung ist per Standard an

„Additional usage is enabled by default“, steht in GitHubs Doku zur nutzungsbasierten Abrechnung (Stand: 22. September 2026). Ist das enthaltene Kontingent aufgebraucht, läuft die Abrechnung weiter. Wer das nicht will, schaltet die Policy „AI credits paid usage“ ab, dann ruht die Nutzung bis zum nächsten Abrechnungszeitraum.

Wer in GitHub Copilot ein Budget anlegt, trifft in der Budget-Doku auf einen weiteren offenen Standardwert: Die Option „Stop usage when budget limit is reached“ „is off by default. Without it, charges continue to accrue past the limit.“

Für Business und Enterprise läuft die Abrechnung seit dem 1. Juni 2026 über GitHub AI Credits (früher Premium Requests), die CLI eingeschlossen. Abgerechnet werden Input-, Output- und Cache-Tokens: „Each token is priced based on the model used“. Was eine Agentensitzung kostet, hängt damit von Modell und Kontextmenge ab, nicht von der Zahl der Prompts.

Pro Nutzer fließt ein Kontingent in den gemeinsamen Pool der abrechnenden Einheit. Der Pool wird am Monatsersten um 00:00 UTC ohne Übertrag zurückgesetzt. Wer viele lange Sitzungen startet, verbraucht das Kontingent der Kollegen mit.

Ist Pool oder Budget erschöpft, springt kein billigeres Modell ein: „There is no automatic fallback to lower-cost models. Code completions and next edit suggestions continue to work.“

Ohne Zusatzeinstellung stoppen nur Nutzer-Budgets, ob universell, je Cost Center oder individuell: „ULBs always enforce a hard stop“. Sie decken Pool und Zusatznutzung ab und werden zuerst geprüft. Budgets für Cost Center, Organisation und Enterprise greifen dagegen erst bei leerem Pool und begrenzen nur die bezahlte Zusatznutzung. Ein Pool für 100 Business-Nutzer umfasst laut Abrechnungsdoku 190.000 AI Credits. Kein Organisationsbudget begrenzt ihn.

Auch diese Grenze hat eine Lücke. Seit dem 2. Juli 2026 kann die CLI in GitHub Actions mit dem eingebauten GITHUB_TOKEN laufen. Abgerechnet wird dann direkt über die Organisation. Die Policy dafür ist standardmäßig an, sobald die CLI-Policy an ist. Laut Changelog gilt: „User-level budgets are not considered when billing directly to the organization“. Die einzige Budgetart, die ohne Zusatzeinstellung stoppt, greift also genau dort nicht, wo niemand am Terminal sitzt.

Prüfreihenfolge der Copilot-Budgets von oben nach unten: Nutzer-Budget, gemeinsamer Pool, bezahlte Zusatznutzung. Daneben die CLI in Actions, bei der das Nutzer-Budget nicht greift.

Ohne Zusatzeinstellung stoppt nur das Nutzer-Budget. Genau diese Grenze fehlt, wenn die CLI in Actions über die Organisation abgerechnet wird.

Im Autopilot-Modus arbeitet der Agent selbstständig weiter, laut Autopilot-Doku gilt: „AI credits are consumed without your direct involvement.“ Nach fünf automatischen Fortsetzungen pausiert er standardmäßig (--max-autopilot-continues), eine Grenze in Credits ist das nicht.

Eine Grenze in Credits gibt es seit dem 1. Juli 2026 als Public Preview: --max-ai-credits oder /limits set (Doku). Sie ist weich, denn „If a response is in progress when the limit is reached, that response completes.“ Und sie setzt der Nutzer selbst.

Die Lizenz ist ein fester Posten pro Kopf, der Tokenverbrauch eines Agenten im Autopilot ist es nicht. Kontingente und Modellpreise stehen im Kostenüberblick zu KI-Coding-Tools.

Rechte im Terminal: was managed settings erzwingen und was nicht

Zentrale Vorgaben für die Rechte des Agenten stehen in managed-settings.json. Die Vorgaben kommen auf drei Wegen auf den Rechner: server-managed aus einem .github-private-Repo der Enterprise, per MDM oder als Datei, etwa /etc/github-copilot/managed-settings.json. Unter macOS und Linux muss diese Datei root gehören und darf weder für die Gruppe noch für andere Nutzer schreibbar sein. Bei Konflikten gilt: MDM vor Server, Server vor Datei, Datei vor Nutzer.

Der Server-Kanal hat zwei dokumentierte Lücken. Laut Deploy-Doku erreicht er nur Nutzer, deren Lizenz aus der eigenen Enterprise stammt. Scheitert der Abruf ohne Cache, ist die Vorgabe „unavailable for that session“, die Sitzung läuft ohne sie. Dieses Fail-open-Verhalten, im Fehlerfall offen statt gesperrt, ist laut changelog.md im CLI-Repo seit Version 1.0.78 vom 3. August 2026 Absicht.

Harte Vorgaben verteilt man deshalb per MDM oder als Datei, denn so gelten sie laut Doku „regardless of where they receive their GitHub Copilot license“. Wer beim Server bleibt, setzt zusätzlich forceRemoteSettingsRefresh (seit 1.0.81 fail-closed).

Rangfolge der drei Wege für managed-settings.json: MDM vor Server vor Datei vor Nutzer. Der Server-Kanal trägt zwei markierte Lücken, MDM und Datei gelten unabhängig von der Lizenzherkunft.

Der Server-Kanal steht im Rang über der Datei, hat aber zwei dokumentierte Lücken. Harte Vorgaben gehören deshalb in MDM oder Datei.

Zentral erzwingen lassen sich inzwischen (Stand: 22. September 2026, CLI 1.0.87):

  • Keine Pauschalfreigabe, seit dem 17. Juni 2026: permissions.disableBypassPermissionsMode: "disable" unterdrückt --yolo, --allow-all und die --allow-all-*-Flags beim Start und sperrt /yolo und /allow-all.
  • Deny-, Ask- und Allow-Regeln mit Selektoren wie Shell(), Edit() oder Domain(). GitHub schreibt dazu im Changelog: „Managed restrictions can't be weakened by user or workspace settings, auto-approval, or previously saved approvals.“ Seit 1.0.85 erfassen Edit-Regeln auch sed -i und Shell-Umleitungen.
  • Eine MCP-Allowlist über allowedMcpServers und deniedMcpServers, abgeglichen über URL oder Startbefehl. Die ältere Registry-Allowlist prüft nur Namen oder ID und ist laut GitHub durch Ändern von Konfigurationsdateien umgehbar.
  • Policy-Hooks in /etc/github-copilot/policy.d/ oder C:\ProgramData\GitHub\Copilot\policy.d\, die Nutzer weder ändern noch per disableAllHooks abschalten können. Ihre Grenze steht in der Hooks-Referenz: „Timeouts are always fail-open, including for preToolUse and admin-deployed policy hooks.“

Die Sandbox lässt sich seit CLI 1.0.76 vom 29. Juli 2026 als Mindeststandard vorgeben, per MDM ab 1.0.77. Laut Referenz der managed settings übersteuert enabled: true auch --no-sandbox, failIfUnavailable: true blockiert die Ausführung, statt ohne Sandbox weiterzumachen, und allowBypass: false verbietet Ausnahmen pro Befehl. Auch die erzwungene Sandbox deckt nicht alles ab: Eingebaute Datei-Werkzeuge schützt sie laut GitHub nur softwareseitig, entfernte MCP-Server gar nicht. Was die Sandbox selbst abschirmt, steht im Beitrag zur lokalen Sandbox für Coding-Agents.

Fertig ist sie nicht. Die lokale Sandbox ist seit dem 2. Juni 2026 in der Public Preview. Version 1.0.79 hat ihre Schlüssel ohne Migration umbenannt. Ob die zentrale Vorgabe ohne Experimentalmodus greift, beschreibt die Doku widersprüchlich. Die Vorgabe gehört deshalb vor dem Rollout auf einen Testrechner.

Dass sich die eingebaute Einstufung täuschen lässt, belegt CVE-2026-29783, Schweregrad hoch. Nur lesende Befehle laufen ohne Rückfrage. Bis Version 0.0.422 ließ sich genau diese Einstufung mit Bash-Parameterexpansion wie ${var@P} umgehen, laut Advisory per Prompt Injection über Repository-Dateien oder Antworten von MCP-Servern. Behoben ist das in 0.0.423, das Advisory erschien am 6. März 2026.

Hier endet die Reichweite der Datei. Weil die managed settings autoUpdate nicht abdecken, entscheiden Installationsweg und lokale Konfiguration, ob ein Sicherheitsfix wie dieser auf jedem Rechner ankommt. Für lokales BYOK, also einen eigenen Anbieterschlüssel, gilt laut Admin-Doku: „not controlled by enterprise policies“.

Datenschutz bei GitHub Copilot: was die CLI übermittelt und unter welchem Vertrag

Laut GitHubs Doku zur CLI bildet jede Eingabe mit Kontext einen Prompt, der über GitHub an ein Sprachmodell geht. Dass auch Befehlsausgaben und gelesene Dateiinhalte in spätere Prompts eingehen, steht nicht ausdrücklich in der Doku, ergibt sich aber aus der Arbeitsschleife eines Agenten.

Alle Angaben in diesem Abschnitt stammen aus Herstellerdoku, FAQ und Vertrag. Eine eigene Messung liegt nicht vor. Die Messung des Netzverkehrs von vier Coding-Agents auf diesem Blog betraf Individual-Tarif und Editor, nicht den Business-Tarif.

Für Business und Enterprise schließt GitHub Training aus: „GitHub does not use either Copilot Business or Enterprise data to train its models“, heißt es in der Plans-FAQ. Die Vertragsgrundlage hängt vom Beschaffungsweg ab. Für direkte Neuabschlüsse seit dem 5. März 2026 gelten die Generative AI Services Terms und das GitHub Customer Agreement (Vertragsänderungen). Bei Kauf über Microsoft gelten die Microsoft Product Terms.

§3 der Generative AI Services Terms (Fassung März 2026): „GitHub will not use Inputs or Outputs to train generative AI models, unless you have given us documented instructions to do so.“ Die Terms gelten unabhängig vom Produktnamen, also auch für die CLI. Welche Bedingungen ein bestehender Vertrag enthält, klärt der Einkauf vor der Freigabe.

Eine Aufbewahrungszusage für die CLI fehlt dagegen. Die Plans-FAQ nennt für Zugriffe außerhalb der IDE 28 Tage für Prompts und Vorschläge, die IDE-Zusage „Not retained“ gilt also nicht fürs Terminal. Die FAQ ist allerdings undatiert.

§6 der Terms verweist für Fristen auf die Produktdoku. Die nennt für die CLI keine eigene Frist (Stand: 22. September 2026). Der Datenschutz sollte die Frist schriftlich bei GitHub erfragen, bevor die CLI ins Verarbeitungsverzeichnis kommt.

Bei Claude Fable 5 und 5.1 bewahrt zusätzlich Anthropic Daten auf. Die Seite zum Modell-Hosting sagt: „Anthropic retains data, including prompts and outputs, by default“. Zero Data Retention, also keine Speicherung beim Anbieter, gibt es nur auf Antrag und befristet bis Ende 2026. Wer diese Modelle ohne genehmigte Ausnahme freigibt, gibt die Aufbewahrung mit frei.

Content Exclusion gilt für die CLI in Business und Enterprise erst seit dem 2. September 2026. Wer die Regeln nur in der IDE geprüft hat, testet sie im Terminal nach.

Bei lokalem BYOK gehen Prompts, Code-Kontext und Antworten direkt zum konfigurierten Anbieter, nicht über GitHub. Für diese Verarbeitung muss der Datenschutz die Bedingungen des Anbieters prüfen. Abgerechnet wird laut GitHub (November 2025) ebenfalls nach dessen Bedingungen.

Ein lokal betriebenes Modell allein bedeutet noch keinen Offline-Betrieb. Die Telemetrie geht auch dann an GitHub, laut Doku ohne Prompts und Code, aber mit Nutzungsmetadaten. Abschalten lässt sie sich nur lokal mit COPILOT_OFFLINE=true, eine Policy dafür gibt es nicht (Stand: 22. September 2026). Vollständige Netzwerkisolation verspricht die BYOK-Doku nur, wenn auch der Anbieter lokal läuft.

Drei Datenwege der Copilot CLI: Prompts über GitHub zum Sprachmodell, Telemetrie an GitHub und bei lokalem BYOK Prompts direkt zum eigenen Anbieter, an GitHub vorbei.

Ein eigener Anbieter nimmt die Prompts aus dem GitHub-Weg, die Telemetrie aber nicht. Die lässt sich nur auf dem Rechner abschalten.

GitHub Copilot mit Data Residency setzt GHE.com voraus

GitHubs dokumentierter Weg zu einer EU-Region für Copilot setzt GitHub Enterprise Cloud mit Data Residency auf GHE.com voraus (Stand: 22. September 2026). Laut Changelog vom 13. April 2026 wird die CLI dort unterstützt.

Auch dort ist die Regionsbindung ein Opt-in. Ohne Policy liegen Copilot-Daten laut GitHubs Seite zur Datenspeicherung standardmäßig außerhalb der Region. Erst die Policy „Restrict Copilot to data residency compliant models“ hält Code, Prompts und Antworten während der Inferenz in der Region (Doku). Jede so verarbeitete Anfrage kostet 10 % mehr AI Credits.

Wer im Audit-Log steht, wenn die CLI handelt

„The audit log does not include client session data, such as the prompts a user sends to Copilot locally. A custom solution is required …“, schreibt GitHub unter Review audit logs (Stand: 22. September 2026).

Im Abschnitt „Audit logging“ nennt die Admin-Doku nur Änderungen an Enterprise-Policies, die die CLI betreffen. Wer die Freigabe umstellt, steht im Log, wer danach Shell-Befehle ausführen lässt, nicht. Die Agenten-Felder wie actor_is_agent gehören zum cloud agent.

Eine Ausnahme gilt nur für Enterprises mit Enterprise Managed Users, also vom Unternehmen verwalteten Konten, und Data Residency auf GHE.com. Seit dem 2. Juli 2026 können diese Enterprises auch Prompts und Tool-Aufrufe aus CLI-Sitzungen streamen, etwa an ein SIEM (Public Preview).

Pull Requests der CLI laufen unter dem Namen der Person, die die Sitzung gestartet hat: „You are marked as the pull request author“ (About Copilot CLI). Ein Commit ist nur am Trailer Co-authored-by als Agentenarbeit erkennbar. Die Option includeCoAuthoredBy hängt ihn standardmäßig an, lässt sich im Repo aber auf false setzen.

Gezählt wird die CLI-Nutzung trotzdem. Die Usage-Metrics-API weist sie laut Metrik-Doku getrennt aus (daily_active_cli_users, totals_by_cli), zum Dashboard heißt es dagegen: „These charts do not include Copilot CLI usage.“

Für die Sitzungsinhalte verweist GitHub auf Eigenbau: „some companies use custom hooks to send Copilot CLI events to their own logging service.“ Der OpenTelemetry-Export lässt sich dafür über den Schlüssel telemetry in den managed settings zentral vorgeben, die Produkttelemetrie an GitHub nicht. Inhalte erfasst er nur mit captureContent, das standardmäßig aus ist. Was ankommt und was bei einem Timeout der Policy-Hooks in policy.d/ fehlt, klärt der Pilot.

Im Changelog vom 26. Februar 2026 kündigte GitHub mehr Sitzungsdaten auch für die CLI an. Die Umsetzung meldet bis zum 22. September 2026 kein späterer Changelog.

Copilot CLI vs. Claude Code: Vergleich auf Governance-Achsen

Die Tabelle vergleicht GitHub Copilot CLI und Claude Code nur dort, wo eine Organisation etwas freischaltet, begrenzt, protokolliert oder unterschreibt.

AchseCopilot CLIClaude Code
Zentrale VorgabenPolicy „Copilot CLI“ plus managed-settings.json per Server, MDM oder Datei, Server-Kanal ohne Cache fail-open (Doku, Stand: 22.09.2026)managed-settings.json per Datei, MDM oder aus der claude.ai-Konsole, Letzteres nur mit Teams/Enterprise und direkter Verbindung zu api.anthropic.com (Doku, Server, Stand: 22.09.2026)
Budget-GrenzeZusatznutzung standardmäßig an. Nutzer-Budgets stoppen immer, auch im Pool. Budgets für Cost Center, Organisation und Enterprise begrenzen nur die Zusatznutzung und stoppen nur mit „Stop usage“ (Standard aus). Bei Abrechnung über die Organisation (Actions) greifen Nutzer-Budgets nicht (Doku, Stand: 22.09.2026)Spend Limits für Organisation, Gruppe und Mitglied, Workspace-Limits in der Console, bei Cloud-Anbietern deren Budgetwerkzeuge (Doku, Stand: 22.09.2026)
Rechte und Sandbox--yolo zentral sperrbar, zentrale deny/ask/allow-Regeln, lokale Sandbox als Public Preview vorgebbar (Doku, Stand: 22.09.2026)Bypass- und Auto-Modus zentral sperrbar (disableBypassPermissionsMode, disableAutoMode), OS-gestützte Bash-Sandbox mit sandbox.failIfUnavailable (Doku, Sandbox, Stand: 22.09.2026)
AuditAudit-Log zeigt Policy-Änderungen, keine Terminal-Sitzungen. Sitzungsdaten nur über eigene Hooks, OTel-Export oder Session-Streaming (EMU mit GHE.com, Preview) (Doku, Stand: 22.09.2026)OpenTelemetry-Events als Audit-Quelle, verwalteter Endpunkt übersteuert Entwicklervariablen, Compliance API liefert Transkripte für Enterprise-Konten (Doku, API, Stand: 22.09.2026)
Modelle und BYOKModelle mehrerer Anbieter unter der Modell-Policy, lokales BYOK ohne Policy (Doku, Stand: 22.09.2026)nur Claude-Modelle, über Teams/Enterprise, Console, Bedrock, Google Cloud, Microsoft Foundry oder LLM-Gateway (Doku, Stand: 22.09.2026)
VertragDirektkauf seit 5. März 2026: GitHub Generative AI Services Terms plus GitHub Customer Agreement, bei Kauf über Microsoft der Microsoft-Vertrag (Terms, Stand: 22.09.2026)Commercial Terms of Service, über Bedrock oder Google Cloud der bestehende Cloud-Vertrag (Doku, Stand: 22.09.2026)

Zu Codex vs. Copilot nur so viel: Die Codex CLI von OpenAI bringt mit requirements.toml ein drittes Regelwerk mit, das Freigaberegeln, Sandbox, MCP und Marketplaces beschränkt (Doku, Stand: 22.09.2026).

Teamstandards im Repo: Anweisungen, Skills, MCP und Hooks für die Copilot CLI

Im Repo nutzen Copilot CLI und Claude Code vieles gemeinsam, anders als bei den zentralen Vorgaben (Stand: 22.09.2026). Die Copilot CLI liest AGENTS.md und CLAUDE.md neben ihren eigenen Anweisungsdateien (Doku). Claude Code liest AGENTS.md erst seit Version 2.1.277 direkt und nur, wenn weder CLAUDE.md noch CLAUDE.local.md existiert. Laut Doku gilt das noch nicht für Bedrock, Vertex und Foundry. Die gemeinsame Datei bleibt deshalb CLAUDE.md, die ein bestehendes AGENTS.md per @AGENTS.md einbindet. Getrennt bleiben pfadspezifische Regeln: .github/instructions/ für die Copilot CLI, .claude/rules/ für Claude Code.

Geteilt werden auch Skills, MCP-Server, Hooks und Plugins. Die Copilot CLI lädt Skills aus .claude/skills/ (Doku), Projekt-MCP-Server aus .mcp.json, sobald der Nutzer dem Ordner vertraut (Doku), Hooks aus .claude/settings.json samt Claude-Code-Eventnamen (Referenz) und Plugins mit .claude-plugin/plugin.json (Repo).

Die managed-settings-Schlüssel der Copilot CLI heißen wie bei Claude Code, etwa disableBypassPermissionsMode oder allowedMcpServers. Pfade und Auslieferung unterscheiden sich aber. Wer beide Agenten betreibt, pflegt einen Teamstandard im Repo und zwei Regelwerke für Policy, Budget und Rechte. Warum dieses Nebeneinander tragfähiger ist als eine Migration, zeigt der Beitrag über Layering von Copilot und Claude Code statt Migration.

Prüfliste: was vor der Freigabe entschieden sein muss

Vor der ersten Sitzung muss nur die CLI freigeschaltet werden. Alles andere bleibt beim Standardwert, bis jemand es ändert. Jede Zeile braucht trotzdem eine Entscheidung: Einstellung ändern, Voraussetzung prüfen oder eine verbleibende Grenze ausdrücklich akzeptieren.

ReglerStandard oder dokumentierte GrenzeEbeneEntscheidung vor dem Rollout
Policy „Copilot CLI“Admin muss freischalten, bei mehreren Organisationen gilt die freizügigste EinstellungEnterprise-Konto / Organisationauf Enterprise-Ebene festlegen statt „Let organizations decide“
Policy „AI credits paid usage“anEnterprise-Konto / Organisationnur zusammen mit Budget-Stopp eingeschaltet lassen
Budget-Option „Stop usage“ausEnterprise-Konto / Organisationfür jedes Budget oberhalb der Nutzerebene einschalten
Nutzer-Budgetstoppt hart, sobald angelegt, auch im PoolEnterprise-Konto / Organisationuniverselles Budget anlegen
CLI in Actions, abgerechnet über die Organisationan mit der CLI-Policy, ohne Nutzer-BudgetEnterprise-Konto / Organisationabschalten oder Organisationsbudget mit Stopp
Kanal der managed settingsserver-managed ist ohne Cache fail-openmanaged settingsMDM oder Datei, sonst forceRemoteSettingsRefresh
--allow-all, /yolonutzbarmanaged settingspermissions.disableBypassPermissionsMode: "disable"
MCP-Serverkeine Allowlist, GitHub-MCP-Server eingebautmanaged settingsallowedMcpServers statt der umgehbaren Registry-Allowlist
Lokale Sandbox (Public Preview)ausmanaged settingssandbox.enabled: true, sandbox.failIfUnavailable: true und sandbox.allowBypass: false setzen, Wirkung mit der eingesetzten CLI-Version im Pilot testen
Content Exclusiongreift in der CLI seit 2. September 2026Enterprise, Organisation, Repobestehende Ausschlüsse mit der CLI nachprüfen
Data Residencyaus (Opt-in)Enterprise-Konto auf GHE.comGHE.com-Voraussetzung prüfen, Residency-Policy ausdrücklich einschalten
AuditAudit-Log zeigt nur Policy-ÄnderungenRechner, managed settings, APIOTel-Export per telemetry vorgeben, captureContent festlegen, Policy-Hooks ergänzen (Timeouts fail-open), Nutzung per Metrics-API abfragen
AnweisungsdateiCLI kombiniert alle gefundenen Dateien ohne VorrangregelRepogemeinsame Grundregeln nur in einer Datei pflegen (nutzt das Team auch Claude Code, dann in CLAUDE.md), pfadspezifische Regeln getrennt halten und auf Widersprüche prüfen

Stand: 22. September 2026, Copilot CLI 1.0.87. Bei zwei bis drei Releases pro Woche muss man jede Zeile vor der Freigabe für ein weiteres Team erneut mit Changelog und Doku abgleichen.

Weiterlesen

Nächster Schritt

Interesse an einer KI-Schulung für Ihr Entwicklerteam? Coding Agents meistern: Assessment vorab, drei Tage Schulung am eigenen Code, danach 30 Tage Transfer. Nach sechs Wochen sehen Sie an eigenen Daten, was sich geändert hat.

Lesen Sie hier regelmäßig mit? Sie können antonioagudo.com bei Google als bevorzugte Quelle markieren, damit diese Inhalte in Ihren Suchergebnissen sichtbarer bleiben.