Agenten-Sandbox: Was sie schützt, was nicht

Am 07.10.2026 hat GitHub das lokale Sandboxing für Copilot allgemein verfügbar gemacht, für die Copilot CLI, die Copilot-App und VS-Code-Sitzungen über den Agent Host. Damit haben vier verbreitete lokale Coding-Agenten alle eine eingebaute Sandbox: Copilot, Claude Code, Codex und Cursor.

Erledigt ist das Thema damit nicht, denn "hat eine Sandbox" sagt wenig. Bei zwei der vier Werkzeuge ist sie ab Werk ausgeschaltet. Bei allen vieren läuft ein Teil des Agenten an ihr vorbei. Und ob der Agent sie selbst verlassen darf, ist eine Einstellung, die die wenigsten kennen. Wer die Sandbox als Sicherheitsargument gegenüber dem eigenen Team oder der IT-Sicherheit verwendet, sollte diese drei Punkte beantworten können.

Nachfragen ist keine Grenze

Coding-Agenten haben zwei verschiedene Schutzmechanismen, die gern verwechselt werden.

Der erste sind Berechtigungen: Der Agent fragt, bevor er etwas tut, oder ein Regelwerk entscheidet für dich. Das ist eine Entscheidung auf Ebene des Werkzeugs. Sie hängt daran, dass der Agent den Befehl richtig einschätzt und du die Rückfrage tatsächlich liest. Nach der dreißigsten Bestätigung am Tag liest niemand mehr.

Der zweite ist die Sandbox: Das Betriebssystem setzt durch, welche Dateien und welche Netzwerkziele ein Prozess erreichen kann. Ob der Agent den Befehl für harmlos hielt, spielt dann keine Rolle mehr. Ein curl an eine fremde Domain scheitert an einer harten Domain-Liste, auch wenn es tief in einem Installationsskript steckt, das niemand gelesen hat. Genau dieser Fall ist der Kern der Clean-Repo-Falle.

Technisch sind die eingebauten Sandboxes leichtgewichtig. Unter macOS nutzen alle vier Seatbelt, unter Linux bubblewrap oder Landlock mit seccomp. Das sind Prozess-Einschränkungen, keine virtuellen Maschinen. GitHub schreibt das in der Copilot-Doku ausdrücklich dazu: Befehle laufen weder in einer VM noch in einem Container.

Die vier im Vergleich

Stand 08.10.2026, jeweils nach der Dokumentation des Herstellers:

Zu jedem Werkzeug gehört eine Besonderheit, die in der Tabelle keinen Platz hat.

Copilot baut auf Microsofts MXC auf, einer MIT-lizenzierten Schicht, die eine Richtlinie in die jeweilige Betriebssystem-Technik übersetzt. Unter Windows ist der Netzwerkschutz schwächer als auf den anderen Plattformen, weil er darauf angewiesen ist, dass Programme die Proxy-Einstellungen beachten. Lokale MCP-Server und Language Server laufen standardmäßig mit in der Sandbox, anders als bei Claude Code und Cursor. MXC selbst ist laut heise seit dem 07.10.2026 auf Windows 11 allgemein verfügbar.

Claude Code schränkt beim Dateizugriff in der Voreinstellung nur das Schreiben ein. Lesen darf ein Befehl in der Sandbox fast den ganzen Rechner, die Doku nennt als Beispiele ausdrücklich ~/.ssh und ~/.aws/credentials. Wer das nicht will, muss die Pfade über sandbox.credentials oder sandbox.filesystem.denyRead sperren. Auf nativem Windows gibt es keine Sandbox, dort hilft nur WSL2.

Codex ist am strengsten voreingestellt: Sandbox an, Netzwerk aus, .git innerhalb des Arbeitsverzeichnisses schreibgeschützt. Der Ausweg heißt --dangerously-bypass-approvals-and-sandbox, kurz --yolo, und schaltet beides auf einmal ab. OpenAI stuft den Schalter in der Doku selbst als nicht empfohlen ein.

Cursor kombiniert die Sandbox mit einem Klassifikator. Im Modus Auto-review laufen freigegebene Befehle direkt, andere Shell-Befehle nach Möglichkeit in der Sandbox, und über den Rest entscheidet ein Sprachmodell im Cursor-Backend. Cursor weist in der Doku selbst darauf hin, dass dieser Klassifikator keine Sicherheitsgrenze ist. Das Lesen außerhalb des Projekts ist in der Voreinstellung ohne Rückfrage erlaubt. Unter Windows läuft die Linux-Sandbox in WSL2, eine native Windows-Sandbox hat Cursor laut eigenem Blog noch nicht.

Was an der Sandbox vorbeiläuft

Die Sandbox umschließt Shell-Befehle und die Prozesse, die sie starten. Der Agent besteht aber aus mehr als Shell-Befehlen.

flowchart TB
  A["Coding-Agent"] --> B["Shell-Befehle"]
  A --> C["Datei- und<br/>Web-Werkzeuge"]
  A --> D["MCP-Server,<br/>Hooks"]
  B --> E["Sandbox des<br/>Betriebssystems"]
  C --> F["Nur Regeln<br/>des Werkzeugs"]
  D --> G["Oft volle<br/>Nutzerrechte"]
  class E success
  class F decision
  class G abort
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef abort fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5

Eingebaute Datei- und Web-Werkzeuge. Wenn der Agent eine Datei über sein eigenes Lese- oder Schreibwerkzeug anfasst, startet er dafür keinen Shell-Prozess. Bei Claude Code folgen Read, Edit, Write und WebFetch deshalb den Berechtigungsregeln und nicht der Sandbox: Ein gesperrter Lesepfad hält das Read-Werkzeug nicht auf, eine Domain-Liste begrenzt WebFetch nicht. Copilot prüft die Richtlinie in seinen Datei-Werkzeugen selbst, laut Doku nur nach bestem Bemühen.

MCP-Server und Hooks. Bei Claude Code laufen lokale MCP-Server, Hooks, Language Server und Hilfsbefehle wie die Statuszeile mit deinen vollen Rechten. Bei Cursor laufen MCP-Aufrufe außerhalb der Sandbox. Bei Codex filtert der Netzwerk-Proxy der Sandbox keine MCP-Verbindungen. Entfernte MCP-Server kann ohnehin keine lokale Sandbox einschränken. Wer sich also einen MCP-Server aus einer zweifelhaften Quelle installiert, hat die Sandbox damit umgangen, bevor der Agent den ersten Befehl ausführt. Dasselbe gilt für die Mods von Claude Code, die nicht in der Sandbox laufen und mit deinen Rechten arbeiten.

Der zweite Versuch. Scheitert ein Befehl an der Sandbox, haben alle vier einen Weg nach draußen. Claude Code und Cursor dürfen ihn von sich aus außerhalb wiederholen. Bei Claude Code heißt der Parameter dangerouslyDisableSandbox, und wer den zweiten Versuch freigibt, hängt vom Berechtigungsmodus ab: im manuellen Modus du, im Auto-Mode ein Klassifikator. Bei Cursor prüft ebenfalls der Klassifikator. Copilot kann um eine Ausnahme für einen einzelnen Befehl bitten, solange die Richtlinie das zulässt. Codex fragt, wenn es über die Grenze hinaus muss, und auf Wunsch entscheidet auch dort ein automatischer Prüfer statt des Menschen. Das ist bequem, weil viele Werkzeuge in der Sandbox erst einmal nicht laufen. Es heißt aber auch, dass die Grenze im Zweifel wieder eine Ermessensentscheidung ist.

Die Domain-Liste ist keine Inhaltskontrolle

Die Netzwerkkontrolle der Sandboxes arbeitet mit Hostnamen. Sie entscheidet, wohin ein Prozess sich verbinden darf, und schaut nicht in die verschlüsselte Verbindung hinein. Anthropic warnt in der Doku zu Claude Code deshalb davor, breite Domains wie github.com freizugeben: Über eine erlaubte Domain lassen sich Daten genauso abziehen wie über eine fremde, und Techniken wie Domain Fronting können die Prüfung des Hostnamens unterlaufen.

Bei Claude Code kommt dazu, dass die Domain-Liste in der Voreinstellung nicht hart ist. Will ein Befehl zu einem Host, der nicht auf der Liste steht, fragt Claude Code im manuellen Modus nach. Hart abgelehnt wird erst mit strictAllowlist oder allowManagedDomainsOnly.

Eine Allowlist mit fünf Paketquellen ist ein echter Gewinn. Eine Allowlist, auf der nach drei Wochen jede Domain steht, die irgendwann einmal gebraucht wurde, ist es nicht mehr. Wie ein Team die Liste versioniert und pflegt, steht im Artikel Coding-Agenten im Team sicher betreiben.

Was du einstellen solltest

Für den eigenen Rechner reichen vier Handgriffe:

1. Einschalten. Bei Copilot /sandbox enable, bei Claude Code /sandbox. Copilot merkt sich das für alle künftigen Sitzungen, Claude Code nur für das aktuelle Projekt. Für alle Projekte gehört sandbox.enabled in die ~/.claude/settings.json.
2. Zugangsdaten vom Lesen ausnehmen. SSH-Schlüssel, Cloud-Zugangsdaten und Token-Dateien gehören auf die Sperrliste. Bei Copilot lässt sich zusätzlich festlegen, ob Git- und gh-Zugangsdaten in der Sandbox überhaupt verfügbar sind.
3. Netzwerk eng halten. Mit leerer Liste starten und nur ergänzen, was der Build tatsächlich braucht.
4. MCP-Server wie Software behandeln. Was du nicht ohne Prüfung installieren würdest, gehört auch nicht als MCP-Server in den Agenten.

Für ein Team zählt, ob sich die Sandbox erzwingen lässt. Das geht bei allen vieren, nur unterschiedlich weit:

Für Claude Code nennt die Doku die drei Schlüssel, auf die es ankommt. Mit ihnen ist die Sandbox an, ein fehlendes bubblewrap führt nicht zum stillen Rückfall auf ungeschützte Ausführung, und der zweite Versuch außerhalb ist abgeschaltet. Die Netzwerkgrenze machen sie nicht hart, dafür braucht es zusätzlich einen der beiden Schalter von oben:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Die Kehrseite: Auf nativem Windows beendet sich Claude Code mit dieser Konfiguration beim Start. In gemischten Flotten muss die Vorgabe deshalb pro Betriebssystem verteilt werden, oder die Windows-Kolleginnen und -Kollegen arbeiten in WSL2.

Wann die eingebaute Sandbox nicht reicht

Die eingebaute Sandbox schützt gut gegen den häufigsten Fall: Ein Befehl tut mehr, als der Agent dachte, und will etwas schreiben oder verschicken, das er nicht soll. Dafür ist sie gemacht, und dafür lohnt sie sich sofort.

Sie schützt nicht gegen alles, was im Agenten selbst läuft, und sie ist keine harte Isolation gegen einen entschlossenen Angreifer. Wer Agenten unbeaufsichtigt arbeiten lässt, fremde Repositories öffnet oder mit produktiven Zugangsdaten auf demselben Rechner sitzt, braucht eine Schicht mehr: den ganzen Agenten in einem Container oder besser in einer MicroVM. Anthropic empfiehlt genau das für alles, was die Bash-Sandbox nicht erfasst. Wie das mit Docker Sandboxes aussieht, steht in KI-Tools sicher nutzen. Wie wir so einen Container für KIberschutz selbst gebaut haben, mit Proxy-Whitelist und Nachweis, zeigt Coding-Agent im Container: zum Selberbauen.

Die eingebaute Sandbox ersetzt diese zweite Schicht nicht. Sie ist aber die erste, die sich in fünf Minuten einschalten lässt, und bei Copilot und Claude Code muss man das selbst tun.