GitHub hat am 8. September 2026 für Copilot in JetBrains IDEs zentral verwaltete Sandbox-Richtlinien in Public Preview veröffentlicht. Unternehmen können damit festlegen, welche lokalen Ressourcen ein Coding-Agent verwenden darf. Betroffen sind Dateisystem, Netzwerkzugriff, Proxy-Konfiguration, Entwicklerwerkzeuge und auf macOS der Zugriff auf den Keychain.
Ein Entwickler kann verwaltete Sicherheitsregeln nicht lokal überschreiben. Damit wird aus einer persönlichen Copilot-Einstellung eine Grenze, die für ein Team oder eine Organisation zentral vorgegeben werden kann.
Die Sandbox wird zur Unternehmensrichtlinie
GitHub Copilot kann in lokalen Agenten-Workflows Shell-Befehle ausführen. GitHubs Sandbox trennt die Konfiguration in allgemeines Verhalten, Authentifizierung, Dateisystem und Netzwerk.
Ohne zentrale Vorgaben kann ein Nutzer diese Regeln lokal konfigurieren. Mit Enterprise-Policies werden verwaltete Werte im Interface als „managed“ angezeigt und lassen sich nicht mehr ändern. Die Unternehmensrichtlinie hat Vorrang vor der lokalen Einstellung.
Das gilt auch für den Sandbox-Bypass. Copilot CLI kann standardmäßig um Freigabe bitten, wenn ein Befehl innerhalb der Sandbox scheitert und außerhalb ausgeführt werden soll. Setzt die Organisation sandbox.allowBypass auf false, kann ein Entwickler diese Ausnahme nicht genehmigen und die Sandbox für die laufende Sitzung auch nicht deaktivieren.
Damit hängt die tatsächliche Isolation nicht mehr davon ab, ob ein Nutzer bei einem fehlgeschlagenen Befehl eine Ausnahme bestätigt.
Internet und lokales Netz werden getrennt behandelt
GitHubs Sandbox unterscheidet zwischen ausgehenden Internetverbindungen und Zugriffen auf lokale beziehungsweise private Netze. Beide Bereiche lassen sich separat steuern.
Ein Coding-Agent kann für eine Paketinstallation Zugriff auf externe Registries benötigen, ohne deshalb einen internen Datenbankdienst oder einen lokalen Admin-Port erreichen zu müssen.
GitHub unterstützt außerdem einen HTTP-Proxy. Auf Windows wird dieser laut Dokumentation durch die Sandbox erzwungen. Unter Linux und macOS arbeitet die Proxy-Konfiguration über die üblichen Proxy-Umgebungsvariablen; einzelne Tools müssen diese respektieren. Eine zentrale Proxy-Vorgabe hat dort deshalb nicht dieselbe technische Durchsetzung wie unter Windows.
Tool-Caches können Tokens enthalten
Standardmäßig erhält Copilot in der Sandbox Lese- und Schreibzugriff auf das aktuelle Arbeitsverzeichnis. In einem Git-Repository kommt Zugriff auf .git hinzu. Weitere Verzeichnisse können explizit als Read/Write, Read-Only oder Denied konfiguriert werden.
Die Einstellung „Allow dev tool access“ geht darüber hinaus. Sie gibt sandboxed Commands Lesezugriff auf Konfigurationen und Caches von Entwicklerwerkzeugen. GitHub nennt ausdrücklich Package-Manager-Registries und dort gespeicherte Tokens. Gemeinsame Build-Caches können zusätzlich beschreibbar sein.
Ein Build kann diese Dateien benötigen. Dieselben Verzeichnisse können aber Credentials enthalten. Wer nur den Zugriff auf den Repository-Ordner betrachtet, erfasst deshalb nicht alle Ressourcen, die ein Agent während eines realen Builds berührt.
Auf macOS gibt es zusätzlich eine eigene Einstellung für den Keychain. Sie ist standardmäßig deaktiviert und kann nun ebenfalls zentral verwaltet werden.
/ide verbindet Copilot CLI mit JetBrains-Kontext
Das Release enthält neben den Sandbox-Policies eine zweite Änderung: Eine Copilot-CLI-Sitzung kann über /ide mit einer JetBrains IDE verbunden werden. Die Terminal-Sitzung erhält dann Kontext wie Auswahl, Diagnosen und Dateireferenzen aus der IDE.
Auch Umgebungsvariablen aus dem IDE-Terminal und der konfigurierte Python-Interpreter können in diesen Workflow einfließen. Damit wird eine Terminal-Sitzung stärker an den Zustand des geöffneten Projekts gekoppelt.
Je mehr Projektkontext und lokale Entwicklungsumgebung der Agent verwenden kann, desto genauer müssen seine Ausführungsrechte definiert sein. Der Kontext selbst und die Rechte der Shell sind zwei getrennte Ebenen.
Was ein Team zentral festlegen kann
Ein Repository kann für alle Entwickler dieselben Agent-Instruktionen enthalten, während lokal unterschiedliche Netzwerk-, Credential- oder Filesystem-Regeln gelten. Enterprise-Policies reduzieren diese Abweichung.
Eine Organisation kann zum Beispiel erzwingen, dass Copilot keinen Zugriff auf das lokale Netzwerk erhält, keinen Sandbox-Bypass ausführen darf und bestimmte Pfade nicht lesen kann. Der Code bleibt derselbe; die Rechte des Agenten werden Teil der verwalteten Entwicklungsumgebung.
Für produktive Coding-Agenten ist diese Ebene mindestens so relevant wie die Modellauswahl. Ein gutes Modell mit uneingeschränkter Shell, erreichbaren Tokens und freiem Netzwerkzugriff hat ein anderes Risikoprofil als dasselbe Modell in einer begrenzten Umgebung.
GitHubs Implementierung ist noch Public Preview. Auch lokale Copilot-Sandboxes selbst sind laut Dokumentation weiterhin in Public Preview. Für Windows verlangt lokales Sandboxing derzeit einen Windows-Insiders-Build.
Offen bleibt vor allem, welche Policy-Kombinationen im Alltag funktionieren, ohne Builds, Package-Manager oder lokale Entwicklungswerkzeuge ständig zu blockieren. GitHub veröffentlicht für diese neue Enterprise-Funktion bislang keine Daten dazu, wie häufig Teams Sandbox-Bypasses, Netzwerkzugriff oder Dev-Tool-Zugriff tatsächlich benötigen.
Quellen
GitHub Changelog, 8. September 2026: Enterprise-managed sandbox in Copilot for JetBrains https://github.blog/changelog/2026-09-08-enterprise-managed-sandbox-in-copilot-for-jetbrains/
GitHub Docs: Configuring local sandbox settings https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings