GitHub Copilot: Lokale Schutzumgebung ist standardmäßig aus, während vier neue Spitzenmodelle bereitstehen

GitHub hat am 23. September 2026 die lokale Schutzumgebung der Copilot App als Public Preview veröffentlicht und standardmäßig ausgeschaltet. Zwei Tage später brachte der wöchentliche Sammelbericht vom 25. September vier Spitzenmodelle in die Modellauswahl: Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna und Grok 4.7, je nach Tarif. Wer beide Changelogs zusammen liest, erkennt ein Risiko für lokale Agent-Läufe.

Was die lokale Schutzumgebung laut Changelog leistet

Die lokale Schutzumgebung (englisch Local Sandboxing) begrenzt den Zugriff von Agent-Sitzungen auf Dateisystem, Netzwerk und Zugangsdaten, und zwar pro Projekt. Sie gilt für lokale Sitzungen mit Repository und Arbeitsverzeichnis. So steht es im GitHub-Changelog vom 23. September. Es handelt sich um eine Herstellerangabe im Stadium der Public Preview, Änderungen sind vorbehalten. Als Zitat taugt sie, als Sicherheitsgarantie nicht.

Die Projekteinstellungen beschreiben die Richtlinie, welche die App anfordert, sobald eine abgesicherte Sitzung startet. Zentral vom Unternehmen verwaltete Einstellungen können strenger ausfallen. Die tatsächlich geltende Richtlinie kann deshalb enger sein als das, was im Projektdialog angeklickt wurde. Verhält sich eine Sitzung unerwartet, sollte zuerst die Kette gelesen werden: Projekt, Unternehmen, Betriebssystem. Erst danach kommt der Agent selbst unter Verdacht.

Standardmäßig ist die Funktion ausgeschaltet. Sie lässt sich unter Einstellungen, Projekt, „Sandbox new sessions“ aktivieren und gilt dann für neue Sitzungen, nicht für bereits laufende. Änderungen an den Einstellungen für Dateisystem, Netzwerk und Zugangsdaten greifen bei neuen Sitzungen oder wenn eine bestehende Sitzung neu startet. Für eine aktive lokale Sitzung genügt der Befehl /sandbox on, ohne den Projektstandard zu ändern.

Besonders wichtig ist das Verhalten bei fehlender Durchsetzung. Kann das Betriebssystem die angeforderte Richtlinie nicht erzwingen, schlägt die abgesicherte Shell mit einem Fehler fehl. Sie läuft nicht ungeschützt weiter. Dieses Prinzip heißt auf Englisch fail-closed, also „im Zweifel geschlossen“. Unbequem ist es, weil die Sitzung nicht startet. Dafür steht sofort fest, dass der Schutz fehlt, statt es später im Vorfallbericht zu lesen. Nach Ansicht der Redaktion ist dies die wichtigste Zeile im gesamten Changelog, wichtiger als jede Ordnerliste.

Für Teams folgt daraus, dass das Einschalten mehr als ein Klick in der App ist. Betriebssystem, Unternehmensrichtlinie und Projekteinstellungen müssen zusammenpassen, erst dann trägt die Sitzung. Wer nur /sandbox on tippt, aktiviert eine Richtlinie auf einer Maschine, die sie womöglich nicht tragen kann. Dann erscheint der Fehler, und das ist gut so.

https://digital-magazin.de/github-copilot/

Dateien, Netzwerk, Zugangsdaten: drei Stellschrauben mit je eigener Falle

Die Richtlinie besitzt drei Stellschrauben, und bei jeder lässt sich etwas falsch einstellen:

• Dateisystem: zusätzliche Ordner mit Lese- und Schreibrecht, zusätzliche nur lesbare Ordner und ausdrücklich gesperrte Ordner.
• Netzwerk: ausgehender Internetverkehr und lokales Netzwerk, getrennt steuerbar.
• Zugangsdaten: Git-Zugangsdaten für authentifizierte Git-Operationen über HTTPS (Hypertext Transfer Protocol Secure) und Zugangsdaten der GitHub-Kommandozeile (CLI, Command Line Interface) für deren Anmeldung.

Beim Dateisystem müssen Teams wissen, welche Pfade der Agent braucht und welche er niemals sehen soll. Dazu zählen .env-Dateien, SSH-Schlüssel (Secure Shell), lokale Speicher für Zugangsdaten und Nachbarprojekte auf derselben Platte. Gesperrte Ordner bilden die Liste jener Dinge, die sich nach einem Abfluss nicht mehr zurückdrehen lassen.

Das Netzwerk wird häufig unterschätzt. Sind Internetzugriff und lokales Netzwerk offen, genügt ein einziger Lauf, um interne Dienste anzustoßen oder Geheimnisse an eine Adresse zu schicken, die in der Eingabe hilfreich wirkte. Wer das Dateisystem abdichtet und das Netzwerk offen lässt, schließt die Tür zum Flur und reißt die Fenster auf.

Bei den Zugangsdaten entstehen die meisten Vorfälle. Authentifizierte Git-Operationen und die Anmeldung der Kommandozeile sind genau die Kanäle, über die Token und Identitäten in Agent-Läufe geraten. Bleibt die Schutzumgebung aus, läuft der Agent mit dem vollen Zugriffsumfang der Maschine, auch mit einem Spitzenmodell. Das Modell ist dann nicht böswillig, sondern mächtig in einer Umgebung, die keine Grenze gesetzt hat.

Der Befehl /sandbox on wirkt nur auf die aktive Sitzung. Er holt keine abgeflossenen Geheimnisse zurück und ändert den Projektstandard nicht. Die nächste Sitzung startet wieder ohne Schutz, solange der Standard auf „aus“ bleibt. Eine abgesicherte Sitzung macht also noch kein sicheres Projekt.

https://digital-magazin.de/copilot/

Cloud, entfernte Rechner und Kommandozeile bleiben außen vor

Die lokale Schutzumgebung gilt weder für Sitzungen in der Cloud-Schutzumgebung noch für Sitzungen auf entfernten Rechnern (Remote Hosts). Wer per SSH, Tunnel oder WSL (Windows Subsystem for Linux) entfernt entwickelt und lokal absichert, bewegt sich in zwei getrennten Welten. Die lokale Richtlinie schützt die lokale Sitzung, die entfernte Sitzung läuft unter den Bedingungen ihres Rechners.

Die Abgrenzung ist gewollt. Local Sandboxing ist eine Funktion der Copilot App für lokale Sitzungen mit Repository und Arbeitsverzeichnis. Die Cloud hat eigene Regeln, entfernte Rechner bringen die Isolation des Hosts mit oder eben nicht. Wer einem Sicherheitsteam versichert, die Schutzumgebung sei aktiv, und damit nur die App-Einstellung meint, während der produktive Agent auf einem entfernten Rechner ohne dieselbe Richtlinie läuft, schafft ein gefährliches Missverständnis.

Getrennt sind auch die Einstellungen der Copilot App und der Copilot CLI. Wer nur die App härtet, sichert die Oberfläche, die er sieht, und lässt die Schnittstelle offen, die Skripte und Automatisierung nutzen. Beide sollten als eigene Konfigurationsflächen behandelt werden, nicht als „einmal an, überall dicht“.

Der Sammelbericht vom 25. September nennt zudem Slack, Teams, JetBrains und Visual Studio Code. Genannt werden Assisted Approvals in JetBrains, Dev Containers auf entfernten Rechnern in VS Code und der Modellwechsel in Slack. Das sind eigene Isolationsfragen, die nicht in den Satz „Copilot ist jetzt abgesichert“ gepresst werden sollten.

Vier Spitzenmodelle, je nach Tarif sichtbar

Welche der vier neuen Modelle ein Teammitglied in der Auswahl sieht, hängt vom Tarif ab. Laut GitHub Copilot Weekly vom 25. September, das die Veröffentlichungen der Woche ab dem 21. September bündelt, gilt:

• Claude Opus 5.5: Pro Plus, Max, Business, Enterprise
• GPT-6 Sol: Pro Plus, Max, Business, Enterprise
• GPT-6 Luna: Pro, Pro Plus, Max, Business, Enterprise
• Grok 4.7: Pro, Pro Plus, Max, Business, Enterprise

Das sind Herstellerangaben. Der Tarif Pro sieht also Luna und Grok, nicht aber Opus 5.5 und Sol. Wer im Team sagt, alle hätten doch Copilot und damit dieselbe Auswahl, liegt falsch. Die Modellauswahl spiegelt den Tarif, und aufgelistet ist ein Modell noch lange nicht für alle verfügbar.

Die Reihenfolge der Woche ist leicht zu übersehen. Am 23. September kam die Schutzumgebung, standardmäßig aus, am 25. September folgten die Modelle. Im App-Abschnitt desselben Berichts steht außerdem OpenTelemetry über zentral verwaltete Einstellungen. Diese Messdaten-Schnittstelle hilft beim Nachvollziehen, ersetzt aber keine Zugriffsbeschränkung. Beobachtung ohne Schutzumgebung zeigt nur, was eine Sitzung lokal alles durfte.

Wer den GitHub Copilot Agent Mode schon produktiv nutzt, kennt das Muster: Je autonomer der Lauf, desto teurer der Standard „alles offen“. Die Modellauswahl macht den Lauf schlauer und breiter, aber nicht vorsichtiger.

https://digital-magazin.de/vscode/

Warum die Kombination ein Vorfallrisiko ist und was Teams prüfen sollten

Eine standardmäßig ausgeschaltete Schutzumgebung und vier Spitzenmodelle ergeben zusammen ein Setup, in dem Vorfälle entstehen. Die Schutzschiene existiert, ist aber Public Preview und muss aktiv eingeschaltet werden. Die Modelle existieren und sind tarifabhängig verfügbar. In der Mischung aus mächtigem Agent und ungeschütztem Standard fehlen nach dem Lauf Geheimnisse, und anschließend bekommt das Modell die Schuld.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose photo of a mechanical keyboard and blank sticky notes suggesting sandbox defaults and model picker choices, warm desk lamp, photorealistic, no logos, no brand names, no readable text, 16:9

Drei Denkfehler liegen nahe. Erstens wird dem Modell die Schuld gegeben, obwohl es nur den Zugriffsumfang nutzte, den die Umgebung erlaubte. Zweitens wird /sandbox on als Rückgängig-Knopf behandelt, dabei ändert der Befehl nur die aktive Sitzung und schreibt keine Prüfhistorie rückwärts. Drittens werden Projektstandard und Sitzungsschalter verwechselt. Wer nach einem Abfluss das Modell wechselt, etwa von Opus auf Luna, optimiert die falsche Größe: Die Modellwahl steuert die Fähigkeit, die Schutzumgebung den Zugriffsumfang.

Aus demselben Grund darf die Regel nicht lauten, die Schutzumgebung nur für Nutzer von Opus einzuschalten. Sonst bleiben Läufe im Tarif Pro mit Luna oder Grok ungeschützt, obwohl dieselben Risiken für Zugangsdaten und Netzwerk gelten. Ein Pilot im Tarif Max mit Schutzumgebung und ein Normalbetrieb im Tarif Pro ohne sie bilden ein zweistufiges Risikomodell. Es sollte dokumentiert werden, und zwar als bewusstes Risiko, nicht als Zwischenstand.

Public Preview bedeutet, dass sich Bezeichnungen, Richtliniensemantik und das Verhalten in Randfällen noch ändern können. Einführungsanleitungen sollten deshalb änderbar bleiben. Dass der Standard „aus“ ist, erklärt sich durch Opt-in und Reifestufe, entschuldigt aber nicht, ihn in produktiven Agent-Läufen mit Spitzenmodellen zu ignorieren. Zentral verwaltete Einstellungen können strenger sein und erlauben Organisationen, Zugriffsumfang und fail-closed zentral zu setzen, ohne auf einzelne Zustimmungen zu hoffen. Das wirkt aber nur, wenn sie tatsächlich gesetzt sind.

Vor dem nächsten Agent-Lauf lohnt diese Prüfliste:

1. Projekt in der Copilot App öffnen und „Sandbox new sessions“ bewusst ein- oder ausschalten, mit Begründung im Team.
2. Dateisystem: Ordner für Geheimnisse, Schlüssel und Nachbarprojekte sperren und nur lesbar freigeben, wo der Agent nicht schreiben soll.
3. Netzwerk: ausgehenden Internetverkehr und lokales Netzwerk getrennt entscheiden.
4. Zugangsdaten: Git über HTTPS und GitHub CLI nur freigeben, wenn der Lauf sie braucht.
5. Aktive Sitzung: /sandbox on als reine Sitzungsmaßnahme verstehen und den Projektstandard separat setzen.
6. Cloud und entfernte Rechner nicht einrechnen, dort gelten eigene Regeln.
7. App und Kommandozeile getrennt prüfen.
8. Die Tarifübersicht der Modelle kennen: Pro sieht Luna und Grok, Pro Plus und höher zusätzlich Opus und Sol.

Jeder Punkt ist eine Teamentscheidung. Wer sie an eine einzelne Entwicklerin delegiert, bekommt genau die Streuung, aus der Vorfälle entstehen: ein Repository abgesichert, das nächste nicht, eine Sitzung mit /sandbox on, die folgende ohne. Die richtige Reihenfolge wirkt pedantisch: Richtlinie setzen, Durchsetzung durch das Betriebssystem prüfen, Sitzung starten, Modell wählen, Agent laufen lassen. Die bequeme Variante endet damit, dass jemand nach dem Kaffee einen Diff sieht, der nach Arbeit aussieht, und im Log Pfade findet, die niemand freigegeben hat.

Wer die bisherige Berichterstattung zu Enterprise-Sandbox und Keychain kennt, erkennt Isolation, Zugangsdaten und Risiken über mehrere Dateien hinweg wieder. Die lokale App-Einstellung ist dazu ein eigener, nachgezogener Hebel. Auch wer zwischen Copilot und anderen Oberflächen wie Claude Code wechselt, sollte vor dem ersten Lauf die Standardrichtlinie lesen. Die Woche vom 23. und 25. September hat sowohl den Hebel als auch die zusätzliche Leistung geliefert. Umlegen müssen den Schalter die Teams selbst.