Copilot-Sandboxmodus: die illustrierte Anleitung
Lokales Sandboxing hält die Shell-Befehle, Datei-Tools und Netzwerkzugriffe von GitHub Copilot in einer Box auf OS-Ebene. Dieser Walkthrough folgt der offiziellen GitHub-Demo: mit /sandbox aktivieren, die Richtlinie formen, abschalten und ganze Sessions in die Cloud geben.
Kurz zusammengefasst
- Der Sandboxmodus führt Copilots Shell-Befehle, Datei-Tools sowie MCP- und LSP-Server in einer OS-Sandbox aus — Dateien, Netzwerk und Zugangsdaten eingeschränkt, ohne VM oder Container (Seatbelt auf macOS, bubblewrap auf Linux, ProcessContainer auf Windows).
- In der Copilot-App ist Sandboxing standardmäßig aus: App-Einstellungen öffnen, Projekt wählen und "Sandbox new sessions" einschalten. In der CLI: /sandbox enable (experimentell).
- Mit /sandbox die Richtlinie formen — Tabs General, Filesystem und Network in der CLI; zusätzliche Lese-/Schreib- und Lesepfade plus verweigerte Pfade sowie Netzwerk- und Zugangsdaten-Schalter in der App. Änderungen gelten für neue Sessions oder via /restart-session.
- copilot --cloud verlagert die ganze Session in eine von GitHub gehostete Cloud-Sandbox; du steigst über den github.com/copilot/tasks-Link oder den Agents-Tab des Repos wieder ein. Lokale Sandbox-Einstellungen gelten nicht für Cloud-Sessions.
How to run GitHub Copilot in local and cloud sandboxes | demo
Kanal:GitHub (official channel)1:31
GitHub Copilot Sandboxes are SO COOL
Kanal:Gwyneth Peña-Siguenza1:50
Local sandboxing in the GitHub Copilot app (public preview)
Doku:github.blog/changelog
Configuring local sandboxing in the GitHub Copilot app
Doku:docs.github.com
About cloud and local sandboxes for GitHub Copilot
Doku:docs.github.com
Die Frames dieses Guides stammen aus der offiziellen GitHub-Sandbox-Demo — einer sauberen Terminal-Aufnahme. Der Text entstand aus Video und GitHub-Doku; Einstellungsnamen werden wörtlich zitiert.
Screenshots bleiben Eigentum ihrer Urheber und werden mit Quellenangabe als visuelle Referenz genutzt. Lokales Sandboxing ist in der öffentlichen Vorschau — Namen und Verhalten können sich ändern.
Der Walkthrough: 12 Schritte
1 · Lokales Sandboxing einschalten
- 1
Copilot in deinem Repo starten
Starte die Copilot CLI in deinem Projekt. Sandboxing ist ein experimentelles CLI-Feature — der Banner zeigt das /experimental-Abzeichen, und in der Statusleiste sitzt der Sandbox-Indikator, den du jetzt kennenlernst.
Copilot CLI beim Start mit /experimental-Abzeichen und Sandbox-Indikator in der Statusleiste.Ansehen bei 0:08 - 2
/sandbox enable ausführen
Tippe /sandbox, und die Befehlspalette bietet genau zwei Schalter: enable und disable. Wähle enable — das Sandboxing gilt für diese Copilot-Session und jeden Shell-Befehl darin.
![Copilot CLI slash-command menu listing /sandbox enable and /sandbox disable above the /sandbox [enable|disable] prompt hint](/images/guides/copilot-sandbox-tutorial/copilot-sandbox-tutorial-sandbox-enable-autocomplete.webp "Copilot CLI slash-command menu listing /sandbox enable and /sandbox disable above the /sandbox [enable|disable] prompt hint")
Die /sandbox-Autovervollständigung mit enable und disable.Ansehen bei 0:24 - 3
Bestätigen, dass die Session in der Sandbox läuft
Copilot druckt "Sandboxing has been enabled.", und die Statusleiste zeigt neben deinen AI Credits nun "sandbox enabled". Von hier an läuft jeder Agent-Befehl innerhalb der Sandbox.
"Sandboxing has been enabled." — die Bestätigung, die du sehen willst.Ansehen bei 0:12
2 · Festlegen, was die Sandbox erreicht
- 4
Mit /sandbox die Richtlinie öffnen
Das nackte /sandbox öffnet das Configure-sandbox-Panel, gespeichert in settings.json unter `sandbox`. Der Tab General entscheidet, was hineinläuft: Shell-Befehle, MCP-Server, LSP-Server und der macOS-Schlüsselbundzugriff für git- und gh-Credential-Helper.
Der Tab General: Shell, MCP- und LSP-Server plus Schlüsselbundzugriff.Ansehen bei 0:30 - 5
Das Dateisystem eingrenzen
Der Tab Filesystem nimmt dein Arbeitsverzeichnis automatisch in die Lese-/Schreib-Pfade auf und kann Berechtigungen beim Sandbox-Ende zurücksetzen. Tool-Pfade wie ~/.nvm und ~/.npm werden nur lesend eingebunden — erweitere die Liste, wenn deine Toolchain mehr braucht.
Read-only-Pfade für nvm und npm, Arbeitsverzeichnis automatisch enthalten.Ansehen bei 0:32 - 6
Das Netzwerk eingrenzen
Der Tab Network zeigt die drei Hebel: ausgehendes Internet erlauben, lokales Netzwerk erlauben und eine Access-Liste pro Host. Wenn die Aufgabe keine Downloads braucht, dreh hier zuerst an der Stellschraube.
Netzwerkrichtlinie: ausgehend, lokales Netzwerk und Host-Allowlist.Ansehen bei 0:36 - 7
Ganz normal arbeiten — Befehle bleiben in der Sandbox
Arbeite wie gewohnt. Der Agent plant, editiert und führt Befehle aus, während die Statusleiste weiter "sandbox enabled" zeigt. Braucht ein Befehl etwas, das die Richtlinie verbietet, scheitert Copilot laut, statt sich still aus der Box zu schleichen.
Eine SQLAlchemy-Migration, geplant und ausgeführt mit "sandbox enabled" in der Statusleiste.Ansehen bei 0:20
3 · Arbeiten, abschalten oder in die Cloud
- 8
Zurück mit /sandbox disable
Ein Schritt außerhalb der Box nötig? /sandbox disable schaltet das Sandboxing aus — "Sandboxing has been disabled." erscheint und das Sandbox-Abzeichen verschwindet aus der Statusleiste. Du kannst hin- und herschalten, wie die Aufgabe es verlangt.
"Sandboxing has been disabled." — beachte: das Sandbox-Abzeichen ist aus der Statusleiste weg.Ansehen bei 0:38 - 9
Cloud-Sandbox mit copilot --cloud starten
Für schwerere Arbeit starte Copilot mit dem --cloud-Flag (die offizielle Demo kombiniert es mit --yolo; die GitHub-Doku zeigt --cloud --experimental). Die Session läuft in einer kurzlebigen, von GitHub gehosteten Umgebung statt auf deiner Maschine.
copilot --cloud --yolo — die ganze Session verlässt gleich deinen Laptop.Ansehen bei 0:50 - 10
Den Remote-Control-Link holen
Sobald die Remote-Session bereit ist, verbindet Copilot das Remote Control und druckt eine github.com/copilot/tasks/...-URL — ctrl+e zeigt einen QR-Code. Der Arbeitsbaum liegt unter /workspaces/<repo> in der Cloud-Sandbox.
Remote Control verbunden, mit Session-URL und QR-Code-Kürzel.Ansehen bei 1:00 - 11
Bauen und Testen in der Cloud überlassen
Der Agent legt Dateien an, installiert Abhängigkeiten und führt deine Testskripte aus in der Cloud-Sandbox — hier entsteht test_auth.py und die Backend-Suite läuft. Deine Maschine ruht, während in der Statusleiste die Credits ticken.
Tests laufen in der Cloud-Sandbox, bislang 80.4 AI Credits verbraucht.Ansehen bei 1:10 - 12
Von GitHub.com aus beobachten und wieder einsteigen
Die Session taucht im Agents-Tab des Repos als Remote CLI session auf — Fortschritt verfolgen, Nachrichten aus dem Browser schicken und später mit copilot --resume fortsetzen, das lokale und Remote-Sessions auflistet.
Der Agents-Tab von tailspin-toys verfolgt die Cloud-Session live.Ansehen bei 1:14
Wo die Einstellungen leben: Copilot-App vs. Copilot CLI
Lokales Sandboxing existiert auf zwei Oberflächen, und ihre Einstellungen werden getrennt konfiguriert — die eine zu ändern, ändert nie die andere.
- 1Copilot-App: standardmäßig aus. App-Einstellungen öffnen, Projekt wählen und unter "Sandbox" "Sandbox new sessions" einschalten. Die Projekt-Richtlinie beschreibt, was eine Sandbox-Session anfordern darf.
- 2App-Richtlinie: Dateisystemzugriff startet mit Lese-/Schreibzugriff für Workspace und Arbeitsverzeichnis, dazu Listen für zusätzliches Lesen/Schreiben, rein Lesen und verweigerte Pfade; das Netzwerk umfasst ausgehendes Internet und lokales Netz, die Zugangsdaten git und GitHub CLI.
- 3Copilot CLI: Sandboxing ist experimentell — starte mit --experimental (oder /experimental on), dann /sandbox enable, /sandbox disable oder das nackte /sandbox für das Konfigurationspanel. Einstellungen landen in settings.json unter `sandbox`.
- 4Slash-Befehle hängen vom Zeitpunkt ab: /sandbox on oder /sandbox off in einer laufenden Session überschreibt nur diese, vor Session-Start ändert es den Projekt-Default. Mit /restart-session lassen sich Richtlinienänderungen anwenden, ohne die Historie zu verlieren.
- 5Cloud-Sessions sind eine eigene Welt: lokale Sandbox-Einstellungen gelten weder für Cloud-Sandboxes noch für Sessions auf Remote-Hosts, und Cloud-Sandboxing muss erst von einem Org- oder Enterprise-Owner freigeschaltet werden.
Die CLI-Demo in diesem Guide zeigt den schnellsten Weg; der Projekt-Schalter in der App ist der dauerhafte Default, sobald deine Richtlinie steht.
Wenn die Sandbox Nein sagt: fail-closed by design
Die Sandbox ist fail-closed gebaut — kann das OS die angeforderte Richtlinie nicht durchsetzen, bricht der Befehl mit Fehler ab, statt ohne Sandbox zu laufen.
- 1Nicht unterstützte Plattform oder Richtlinie: Ist die angeforderte Richtlinie nicht durchsetzbar, scheitert die Sandbox-Shell mit Fehler — sie fällt nie stillschweigend auf einen Lauf ohne Sandbox zurück.
- 2"Sandbox unavailable": Die App markiert das Problem und bietet nach der Behebung einen Retry-sandbox-Button an.
- 3Die Notluke: Ein "Run outside the sandbox?"-Prompt kann anbieten, abzubrechen, einmal außerhalb der Sandbox auszuführen oder das Sandboxing für die Session auszuschalten — "Re-enable sandbox" dreht es zurück. Das Ganze endet mit dem Neustart und ändert nie Projekt-Defaults.
- 4Enterprise-Owner können das letzte Wort haben: Managed Settings können die Notluke blockieren, und auch dort greift die Durchsetzung nach dem Fail-closed-Prinzip.
Plattform-Notizen: macOS 15+ empfohlen (Seatbelt); Linux braucht bubblewrap 0.5.0+ im PATH plus slirp4netns, util-linux 2.35+, iptables und /dev/net/tun; Windows nutzt die BaseContainer-Stufe von ProcessContainer — ein nicht garantierbarer verweigerter Pfad lässt den Befehl mit unsupported-policy scheitern.