GitHub Copilot App: Lokale Sandbox einrichten und prüfen

Sie aktivieren die Sandbox, doch eine bereits laufende Sitzung behält ihre alten Rechte – oder der Agent fordert für Paketinstallation, lokalen Server und Branch-Push immer wieder zusätzlichen Zugriff an. Meist liegt das Problem nicht am Ein-/Aus-Schalter, sondern am Zusammenspiel von Projektstandard, Sitzungs-Override und den getrennten Regeln für Dateien, Netzwerk und Zugangsdaten.

Nach diesem Leitfaden können Sie eine passende Ausgangsrichtlinie für ein lokales Repository oder einen Worktree wählen, Änderungen auf die richtige Sitzung anwenden und die Grenzen mit Dummy-Daten prüfen. Der kürzeste Ablauf lautet: Sitzungstyp bestätigen → Sandbox new sessions aktivieren → drei Berechtigungsbereiche eingrenzen → Sitzung neu starten oder neu anlegen → sichere Prüfungen ausführen.

GitHub kündigte die Funktion am 23. September 2026 an; sie befindet sich weiterhin in der öffentlichen Vorschau, daher können sich Oberfläche und Verhalten ändern. Merken Sie sich drei Grenzen: standardmäßig deaktiviert, pro Projekt konfiguriert und bei nicht durchsetzbarer Richtlinie Fehler der sandboxed Shell statt stiller Ausführung ohne Schutz.

Zuerst prüfen, ob Ihre Sitzung abgedeckt ist

Die Projektrichtlinie gilt nur für lokale Repository- und Worktree-Sitzungen. Cloud-Sandboxes, Remote-Hosts und GitHub Copilot CLI verwenden andere Mechanismen; prüfen Sie daher zuerst die Tabelle.

Sitzungstyp	Abgedeckt?	Wichtige Grenze
Lokale Repository-Sitzung	Ja	Verwendet die Sandbox-Einstellungen des aktuellen Projekts
Lokale Worktree-Sitzung	Ja	Ein Worktree trennt Branches und Dateien, beschränkt aber nicht den Zugriff auf andere Bereiche des Rechners; diese Berechtigungsgrenze liefert die Sandbox
Cloud-Sandbox-Sitzung	Nein	Verwendet die eigene Isolation der Cloud-Sitzung
Sitzung auf einem Remote-Host	Nein	Die lokale Projektrichtlinie wird nicht auf den Remote-Host angewendet
GitHub Copilot CLI	Separat konfiguriert	Die Sandbox-Einstellungen von Copilot app und Copilot CLI ersetzen einander nicht

Unternehmensweit verwaltete Einstellungen können die tatsächlich wirksame Richtlinie stärker einschränken als die in den Projekteinstellungen angeforderte Richtlinie. Die Projektseite beschreibt deshalb, welchen Zugriff die App anfordert, nicht zwingend den maximalen Zugriff, den die Organisation erlaubt.

So aktivieren Sie die Sandbox für neue Sitzungen

Damit spätere lokale Sitzungen die Projektrichtlinie verwenden, aktivieren Sie Sandbox new sessions und starten anschließend eine neue Sitzung; der Schalter ändert keine bereits laufende Sitzung. Gehen Sie so vor:

1. Öffnen Sie die Einstellungen der GitHub Copilot app.
2. Wählen Sie das Projekt aus, das Sie konfigurieren möchten.
3. Suchen Sie den Abschnitt Sandbox.
4. Aktivieren Sie Sandbox new sessions.
5. Starten Sie eine neue lokale Sitzung.

Der Schalter wirkt nur auf anschließend erstellte Sitzungen. Eine bereits laufende Sitzung wird nicht verändert. Auch spätere Änderungen an Datei-, Netzwerk- oder Zugangsdatenregeln gelten erst für neue Sitzungen oder nach einem Neustart der aktuellen Sitzung.

Um die Richtlinie neu zu laden und den bisherigen Gesprächsverlauf zu behalten, geben Sie in der laufenden Sitzung /restart-session ein.

GitHub empfiehlt für die meisten Projekte, mit der Standardrichtlinie zu beginnen. Sie unterstützt typische Entwicklungsarbeiten wie das Installieren von Abhängigkeiten, die Verbindung zu einem lokalen Entwicklungsserver, das Pushen eines Branches und das Erstellen eines Pull Requests. Schränken Sie sie weiter ein, wenn sich neben dem Projekt sensible Ordner befinden, kein Netzwerkzugriff benötigt wird oder Ihre Zugangsdaten nicht verwendet werden sollen.

Dateien, Netzwerk und Zugangsdaten getrennt begrenzen

Die drei Bereiche sind unabhängig: Dateibeschränkungen deaktivieren keine Zugangsdaten, und deaktivierte Zugangsdaten schützen keinen weiterhin lesbaren sensiblen Ordner. Begrenzen Sie jeden Bereich passend zur Aufgabe, statt alles gleichzeitig abzuschalten.

1. Dateisystem: festlegen, was gelesen und verändert werden darf

Beginnen Sie mit dem kleinsten Dateibereich: Lassen Sie Lesen und Schreiben im Workspace zu und ergänzen Sie weitere Pfade nur bei echtem Bedarf. Standardmäßig kann die Sitzung Workspace und aktuelles Arbeitsverzeichnis lesen und beschreiben; hinzu kommen drei Listen:

• Additional read/write: zusätzliche Ordner, die von Agentenwerkzeugen gelesen und verändert werden dürfen.
• Additional read-only: zusätzliche Ordner, die gelesen, aber nicht verändert werden dürfen.
• Denied: Ordner, auf die nicht zugegriffen werden darf.

Ein genauer angegebener verweigerter Unterordner bleibt gesperrt, auch wenn ein übergeordneter Ordner weiter gefasste Lese- oder Schreibrechte besitzt. Erlauben Sie lieber nur den kleinsten benötigten Pfad, statt das gesamte Home-Verzeichnis zu öffnen und anschließend viele Ausnahmen zu pflegen.

Unter Windows ist eine wichtige Durchsetzungsgrenze zu beachten. Ein verweigerter Pfad kann in den Projekteinstellungen gespeichert werden. Wenn die aktuell verfügbaren Windows-Sandbox-Funktionen diese Sperre jedoch nicht garantieren können, schlägt der Befehl mit unsupported-policy fehl. Er läuft weder mit offengelegtem Pfad weiter, noch wird die Sandbox automatisch abgeschaltet.

2. Netzwerk: Internet und lokales Netzwerk getrennt steuern

Wenn die Aufgabe Abhängigkeiten installiert oder einen lokalen Entwicklungsserver nutzt, sperren Sie nicht automatisch beide Wege; entscheiden Sie getrennt über Internet und lokales Netzwerk. Standardmäßig kann die Sitzung beide erreichen, und Sie können steuern:

• Outbound internet: Zugriff auf GitHub, Paketregistries und andere Internetdienste.
• Local network: Loopback- und lokale Netzwerkverbindungen, einschließlich lokaler Entwicklungsserver.

Netzwerkbeschränkungen können das Installieren von Abhängigkeiten, API-Aufrufe, Vorschau-Server und andere Werkzeuge mit Verbindungsbedarf beeinträchtigen. Eine Netzwerksperre ist daher ein funktionaler Kompromiss und kein folgenloser Sicherheitsschalter.

Für Linux gilt eine besondere Einschränkung: Die Sandbox kann den Zugriff auf das lokale Netzwerk bei gestarteten Prozessen wie Shell-Befehlen sowie lokalen MCP- oder LSP-Servern nicht unabhängig kontrollieren. Die Einstellung greift weiterhin für Vorgänge innerhalb des App-Prozesses, etwa Webanfragen und Remote-MCP-Verbindungen. Prüfen Sie unter Linux deshalb sowohl In-Process-Vorgänge als auch gestartete Prozesse, statt nur einen der beiden Wege zu testen.

3. Zugangsdaten: Git und GitHub CLI getrennt kontrollieren

Für Codeprüfung oder Offline-Analyse deaktivieren Sie Git- und GitHub-CLI-Zugangsdaten zunächst; aktivieren Sie sie nur für Branch-Push oder Pull-Request-Erstellung. Standardmäßig sind authentifizierte Vorgänge verfügbar, und Sie können deaktivieren:

• Git credentials: Zugangsdaten für authentifizierte HTTPS-Git-Vorgänge.
• GitHub CLI credentials: die von GitHub CLI verwendete Authentifizierung.

Eine Deaktivierung kann Vorgänge wie das Pushen eines Branches oder das Erstellen eines Pull Requests verhindern. Dateisystem- und Zugangsdatenrichtlinien sind getrennte Grenzen. Auch bei deaktivierten Zugangsdaten sollten Ordner mit Schlüsseln, Konfigurationen oder anderen sensiblen Inhalten über Dateisystemregeln geschützt werden.

Wann Sie Projekt, aktuelle Sitzung oder einen Vorgang ändern

Ändern Sie das Projekt, wenn spätere Sitzungen die Regel erben sollen; verwenden Sie /sandbox on oder /sandbox off für die aktuelle Sitzung; nach einer Projektänderung lädt /restart-session die Richtlinie neu.

Aktion	Zeitpunkt der Wirkung	Auswirkung auf andere Sitzungen
Sandbox-Einstellungen des Projekts ändern	Bei neuen Sitzungen oder nach einem Sitzungsneustart	Ändert den Standard, den spätere Sitzungen in diesem Projekt erben
In einer aktiven lokalen Sitzung /sandbox on eingeben	Sofort, als dauerhafter Override für diese Sitzung	Ändert den Projektstandard für andere Sitzungen nicht
In einer aktiven lokalen Sitzung /sandbox off eingeben	Deaktiviert die Sandbox sofort für diese Sitzung	Andere Sitzungen bleiben unverändert; Befehle erhalten dann denselben Datei-, Netzwerk- und Zugangsdatenzugriff wie Ihr Benutzerkonto
Vor dem Start einer Sitzung /sandbox on oder /sandbox off eingeben	Ändert den Projektstandard, den neue Sitzungen erben	Wirkt auf Sitzungen, die danach mit diesem Standard gestartet werden
/restart-session eingeben	Startet die aktuelle Sitzung neu, behält den Verlauf und lädt die Richtlinie erneut	Ändert für sich genommen die Projektrichtlinie nicht

Benötigt ein Werkzeug einen Zugriff, den die Richtlinie nicht erlaubt, kann die App Run outside the sandbox? anzeigen. Abhängig von der wirksamen Richtlinie können Sie abbrechen, genau diesen Vorgang einmal außerhalb der Sandbox ausführen oder die Sandbox für den Rest der aktuellen Sitzung deaktivieren. Ein Enterprise-Eigentümer kann das Ausführen von Werkzeugen außerhalb der Sandbox vollständig unterbinden.

Das Deaktivieren über diese Abfrage überschreibt weder den Projektstandard noch einen bestehenden dauerhaften Sitzungs-Override. Der temporäre Zustand endet beim Neustart oder erneuten Anhängen der Sitzung. Nach der Anzeige Sandbox off for this session können Sie mit Re-enable sandbox wieder aktivieren.

Die sicherere Reihenfolge lautet: zunächst abbrechen und klären, weshalb der Befehl zusätzliche Rechte benötigt. Wird der Zugriff regelmäßig gebraucht, passen Sie die Projektrichtlinie möglichst eng an und starten die Sitzung neu. Führen Sie einen Vorgang nur dann einmalig außerhalb der Sandbox aus, wenn Sie Befehl, Argumente und Auswirkungen geprüft haben. Bei einem unbekannten Repository oder einem aus einer Eingabe dynamisch erzeugten Befehl sollten Sie nicht allein aus Bequemlichkeit die Sandbox für die ganze Sitzung abschalten.

Kann der Host die Richtlinie nicht erzwingen, stoppt der Befehl

Kann das Betriebssystem eine Regel nicht erzwingen, ist ein fehlgeschlagener Befehl das sichere Ergebnis – nicht die automatische Ausführung ohne Sandbox.

Die GitHub Copilot app akzeptiert Sandbox-Einstellungen, bevor feststeht, ob das Betriebssystem alle angeforderten Regeln durchsetzen kann. Die Unterstützung wird geprüft, sobald die erste sandboxed Shell startet.

Kann der Host die angeforderte Richtlinie nicht durchsetzen, gilt:

• Die Shell meldet unsupported-platform oder unsupported-policy.
• Der Befehl wird nicht ohne Sandbox fortgesetzt.
• Zeigt die App Sandbox unavailable, beheben Sie das gemeldete Problem und wählen anschließend Retry sandbox.

Das ist ein Fail-Closed-Verhalten und keine bestmögliche Ausführung. Erfolgreich gespeicherte Einstellungen beweisen daher noch nicht, dass die Richtlinie auf dem aktuellen Rechner aktiv ist. Starten Sie mindestens eine sandboxed Shell, prüfen Sie, dass keine Unsupported-Meldung erscheint, und führen Sie danach eine minimale Verifikation aus.

So prüfen Sie die Richtlinie mit Dummy-Daten

GitHub beschreibt das erwartete Richtlinienverhalten, aber nur ein Test auf Ihrem Rechner bestätigt, dass die Kombination aus Betriebssystem und Regeln funktioniert. Die folgenden Schritte verwenden wegwerfbare Ordner und Dummy-Dateien, ohne echte Schlüssel oder Produktionskonfiguration anzufassen.

Erstellen Sie außerhalb des Workspace wegwerfbare Testordner und legen Sie darin ausschließlich Dummy-Dateien ab. Verwenden Sie keine echten SSH-Schlüssel, Cloud-Zugangsdaten oder Produktionskonfigurationen.

Prüfung	Sichere Vorgehensweise	Erwartetes Richtlinienverhalten
Vererbung an neue Sitzung	Sandbox new sessions aktivieren und eine neue lokale Sitzung erstellen	Die neue Sitzung verwendet die Projektrichtlinie; eine alte Sitzung ändert sich nicht automatisch
Richtlinienänderung anwenden	Eine Regel ändern und /restart-session eingeben	Die Sitzung startet neu, behält den Verlauf und lädt die Richtlinie erneut
Schreibgeschützter Ordner	Einen wegwerfbaren Ordner unter Additional read-only ergänzen, eine Dummy-Datei lesen und anschließend versuchen, eine Testdatei anzulegen	Lesen sollte funktionieren, Schreiben sollte blockiert werden
Verweigerter Ordner	Einen weiteren Testordner unter Denied ergänzen und versuchen, dessen Inhalt aufzulisten oder eine Dummy-Datei zu lesen	Der Zugriff sollte auch dann blockiert sein, wenn ein breiterer Elternpfad erlaubt ist
Internetzugriff	Outbound internet ausschalten und eine harmlose Verbindungsprüfung ausführen	Die externe Verbindung sollte fehlschlagen; anschließend wieder einschalten und vergleichen
Lokales Netzwerk	Local network ausschalten und eine Verbindung zu einem wegwerfbaren lokalen Testdienst versuchen	Das Ergebnis folgt den Fähigkeiten der Plattform; die Linux-Einschränkung für gestartete Prozesse berücksichtigen
Git-Zugangsdaten	Git credentials ausschalten und in einem Test-Repository eine nicht verändernde Authentifizierungsprüfung durchführen	Authentifizierte HTTPS-Git-Vorgänge können nicht mehr verfügbar sein
GitHub-CLI-Zugangsdaten	GitHub CLI credentials ausschalten und eine nicht verändernde Prüfung wie gh auth status ausführen	GitHub CLI sollte die bisherige Authentifizierungsfähigkeit nicht erhalten; genaue Fehlermeldungen können variieren
Fail-Closed-Verhalten	Falls unsupported-platform oder unsupported-policy erscheint, prüfen, dass eine vorgesehene Dummy-Datei nicht angelegt wurde	Der Befehl sollte nicht ohne Sandbox fortgesetzt werden und die beabsichtigte Nebenwirkung nicht eintreten

Löschen Sie danach die Testordner und stellen Sie nur die minimalen Rechte wieder her, die das Projekt tatsächlich benötigt. Testen Sie eine Sperrregel nicht, indem Sie auf ein echtes sensibles Verzeichnis zugreifen.

Welche Ausgangsrichtlinie zu Ihrer Aufgabe passt

Alltägliche Entwicklung, ein unbekanntes Repository und Offline-Analyse sollten nicht dieselbe Richtlinie verwenden. Behalten Sie für normale Arbeit das Nötige, starten Sie bei fremdem Code strenger und deaktivieren Sie offline zuerst Netzwerk und Zugangsdaten.

Alltägliche Entwicklung

Aktivieren Sie die Sandbox, behalten Sie die standardmäßigen Netzwerk- und Zugangsdatenfähigkeiten bei, ergänzen Sie nur wirklich benötigte externe Ordner und sperren Sie benachbarte sensible Verzeichnisse ausdrücklich. Das passt zu normaler Arbeit mit Abhängigkeitsinstallation, lokalen Diensten, Branch-Pushes und Pull Requests.

Prüfung eines unbekannten Repositorys

Erlauben Sie Lesen und Schreiben nur im Workspace, stellen Sie zusätzliches Referenzmaterial schreibgeschützt bereit, deaktivieren Sie Git- und GitHub-CLI-Zugangsdaten standardmäßig und lassen Sie das ausgehende Internet gesperrt, bis die Quellen der Abhängigkeiten verstanden sind. Wird vorübergehend Zugriff benötigt, öffnen Sie eine konkrete Fähigkeit, statt sofort /sandbox off zu verwenden.

Lokale Offline-Analyse

Deaktivieren Sie ausgehenden Internetzugriff und nicht benötigte Zugangsdaten und lassen Sie nur den nötigen Dateizugriff aktiv. Ist auch die Isolation des lokalen Netzwerks wichtig, prüfen Sie unter Linux gestartete Prozesse gesondert, statt anzunehmen, ein einzelner UI-Schalter steuere alle Prozesse identisch.

Diese Profile sind keine von GitHub benannten Voreinstellungen. Sie sind Ausgangspunkte, die aus den von GitHub bereitgestellten Berechtigungsdimensionen zusammengesetzt wurden. Stimmen Sie die endgültige Richtlinie auf Repository, Betriebssystem, Unternehmensregeln und konkrete Aufgabe ab.

Fehler, die die Richtlinie unwirksam oder zu weit machen

Die häufigsten Fehler sind, „gespeichert“ mit „durchgesetzt“ gleichzusetzen und nach der ersten Verweigerung die ganze Sandbox abzuschalten. Die sieben Fälle unten verfälschen den Test oder gewähren zu viel Zugriff.

1. Einen Worktree als Sicherheitsgrenze behandeln. Er trennt parallel bearbeitete Branches und Dateien, verhindert aber nicht, dass Befehle andere Bereiche des Rechners erreichen.
2. Die Richtlinie ändern und in einer alten Sitzung weiter testen. Projektänderungen wirken nicht rückwirkend; starten Sie eine neue Sitzung oder verwenden Sie /restart-session.
3. Annehmen, App und CLI teilten dieselbe Sandbox. Beide werden separat konfiguriert.
4. Erfolgreiches Speichern als Nachweis für Host-Unterstützung ansehen. Ob die Regeln durchsetzbar sind, wird erst beim Start der ersten sandboxed Shell geprüft.
5. Die Bedeutung von /sandbox off übersehen. Von Agenten ausgeführte Befehle erhalten anschließend denselben Zugriffsbereich wie Ihr Benutzerkonto.
6. Identisches Netzwerkverhalten auf allen Plattformen erwarten. Für gestartete Prozesse unter Linux ist eine Einschränkung der lokalen Netzwerksteuerung dokumentiert.
7. Bei jeder Zugriffsverweigerung eine breite Ausnahme verwenden. Meist ist es sicherer, den Bedarf zu prüfen, die kleinste Richtlinienänderung vorzunehmen und die Sitzung neu zu starten.

Ihre nächsten Schritte

Bestätigen Sie zuerst, dass Sie eine lokale Repository- oder Worktree-Sitzung verwenden, und aktivieren Sie Sandbox new sessions. Für alltägliche Entwicklung starten Sie mit der Standardrichtlinie und behalten nur benötigte Ordner, Netzwerkwege und Zugangsdaten; für unbekannten Code oder Offline-Analyse beginnen Sie strenger und öffnen jeweils nur eine Fähigkeit.

Erstellen Sie nach einer Projektänderung eine neue Sitzung oder führen Sie /restart-session aus. Prüfen Sie anschließend Read-only-, Denied-, Netzwerk- und Zugangsdaten-Grenzen mit wegwerfbaren Daten. Bei unsupported-platform, unsupported-policy oder Sandbox unavailable beheben Sie die Kompatibilität, statt mit /sandbox off ein ungeschütztes Ergebnis als erfolgreichen Sandbox-Test zu deuten.

Offizielle Quellen

Prüfen Sie vor und nach der Konfiguration auf diesen GitHub-Seiten die aktuelle Oberfläche, den Geltungsbereich und das Fehlerverhalten.

• Lokales Sandboxing in der GitHub Copilot app konfigurieren
• Local sandboxing in the GitHub Copilot app — GitHub Changelog, 23. September 2026