Sandbox-Richtlinien konfigurieren

Ob ein Agentenlauf in der Sandbox läuft, entscheidet der Server beim Start (--sandbox). Der Schalter Sandboxing aktivieren und die Auswahl Backend unter Einstellungen → Server → Diagnose und Datenschutz sind Einstellungen auf deinem Gerät. Die Hosterkennung der Karte Sandboxing meldet, was der Server-Host umhüllen kann.

Zwei Steuerungen erreichen einen Lauf, und diese Anleitung deckt beide ab: die Aktionsregeln unter Einstellungen → Arbeitsbereich → Agent-Berechtigungen, die entscheiden, was ein Agent pushen, öffnen oder erreichen darf, und das eigene Flag --sandbox des Servers.

Was einen Agentenlauf begrenzt

Sechs Dinge halten einen Agenten. Das erste ist die Betriebssystem-Sandbox, und sie ist die bedingte — die anderen fünf gelten auf jedem Host.

Grenze	Was sie tut
Die Betriebssystem-Sandbox	Seatbelt unter macOS, bubblewrap unter Linux und WSL2. Umhüllt die Claude-Code-CLI, ACP-Adapter und das Werkzeug `bash` des Harness. Fehlt unter Windows und unter Linux ohne `bwrap` und `socat`
Der eigene Worktree	Jede Unterhaltung bekommt einen Copy-on-Write-Checkout. Der ursprüngliche Checkout geht als Schreibverbotspfad in den Lauf ein, und die Sandbox setzt das durch
Vermittelte Zugangsdaten	Der Zugangsdaten-Broker stellt eine Umgebung je Lauf zusammen und widerruft sie beim Abbau. Ihr GitHub-Token kann lesen, aber nicht pushen: Ein Push läuft durch Control Center, das zuerst die Push-Regel fragt
Aktions-Schutzregeln	Jedes verändernde Werkzeug deklariert seine Effektklassen, und die Schutzregel löst sie auf, bevor der Aufruf läuft. Ein `prompt` ohne verbundene zuständige Person wird abgelehnt
Bereinigung der Umgebung	ACP und das Werkzeug `bash` des Harness bekommen eine gefilterte Umgebung. Claude Code über `NoSandboxAdapter` erbt die Umgebung des Hosts
Die Werkzeugfläche des Modus	Ein Nur-Lese-Modus nimmt die den Worktree verändernden Werkzeuge vollständig heraus und verankert das eigene Ausgabe-Verb des Modus, damit er trotzdem liefern kann

Drei Dinge sind schwächer, als sie aussehen:

Nur der eingebaute Harness setzt das Werkzeugtor, die Abschlussverträge und die strukturellen Modusregeln durch. Der Adapter Claude Code tut das nicht. Claude Code startet insbesondere mit --dangerously-skip-permissions, weil ein nicht interaktives claude -p sonst für immer an seiner eigenen Nachfrage hängen bliebe — die eigenen Aufrufe von Claude zum Lesen, Schreiben und Bearbeiten sieht Control Center deshalb nicht und lässt sie auch nicht durch ein Tor, und seine Shell-Befehle prüft nur ein Hook, der die Befehlszeile liest. Wo die Sandbox an ist, ist sie die Grenze darum.
Die prozessinternen Dateiwerkzeuge des Harness (read, write, edit, apply patch, search, find, search_files) laufen im Serverprozess, also begrenzt sie kein Sandbox-Profil. Nur das Werkzeug bash geht durch den gekapselten Befehlsrunner. Ihre Grenze sind die eigene Pfadbeschränkung und die Aktions-Schutzregeln.
Auf einem Host ohne Backend gilt die erste Zeile gar nicht. ACP und das Werkzeug bash des Harness fallen auf die Bereinigung der Umgebung plus die Befehlsrichtlinie zurück. Claude Code erbt die Umgebung des Hosts über NoSandboxAdapter. Der Server sagt das in seinem Startlog. Deins prüfst du weiter unten.

Entscheiden, was ein Agent pushen darf

Es gibt keinen Schalter je Agent für git push, GitHub, Ticketing oder das Netzwerk. Jedes davon ist eine Aktionsregel:

Regel	Eingebauter Standard	Was sie abdeckt
Zu einem Remote pushen	Zuerst fragen	Jedes `git push` zu GitHub, egal mit welchem Adapter
Einen Pull Request öffnen	Zuerst fragen	`gh pr create` und die Pull-Request-Werkzeuge
Eine Review veröffentlichen oder mergen	Zuerst fragen	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
In einen externen Tracker schreiben	Zuerst fragen	Ticket-Schreibvorgänge über die Werkzeuge von Control Center und `gh issue`
Auf das Netzwerk zugreifen	Zulassen	Ob die Sandbox überhaupt ein Netzwerk hat, und die Web-Werkzeuge des Harness

Öffne Einstellungen → Arbeitsbereich → Agent-Berechtigungen
Wähle den Geltungsbereich — Arbeitsbereich, Agent oder Bereich — und in der Zeile der Regel Zulassen, Zuerst fragen oder Verweigern

Auf Branches beschränkte Push-Regeln, etwa eine, die Pushes auf main verweigert, greifen ebenfalls: siehe Schutzregeln.

Kontrollpunkt: Bitte den Agenten, einen Branch zu pushen. Bei Zuerst fragen bekommst du eine Freigabe mit Repo und Refs; bei Verweigern gibt git ! [remote rejected] <ref> (Control Center policy: …) aus.

Wie jede Regel den Lauf erreicht:

Push wird über das durchgesetzt, was der Lauf besitzt. Sein GitHub-Token ist ein Installationstoken der GitHub App, das nur lesen darf: Es kann Inhalte lesen und mit Pull Requests arbeiten. Seine Git-Konfiguration schickt jeden GitHub-Push an ein Loopback-Gateway auf cc_server, das die Regel fragt und den Push erst dann mit einem Schreib-Token weiterleitet, das der Agent nie sieht. Das Gateway leitet nur an das eigene Repo des Worktrees oder an ein mit dem Arbeitsbereich verknüpftes GitHub-Repo weiter. Das gilt für jeden Adapter.
Pull Requests und Issues aus einer Shell werden an der Befehlszeile erkannt, im Werkzeug bash des Harness und, über einen Hook, im Werkzeug Bash von Claude Code. Ein Agent, der den Befehl versteckt (ein Skript, eval, ein direkter API-Aufruf), kommt an dieser Prüfung vorbei, aber nicht am Push-Gateway.
Ticketing-Schlüssel landen nie in der Sandbox. Agenten schreiben Tickets über die MCP-Werkzeuge von Control Center, die die Regel fragen.
Netzwerk wird einmal aufgelöst, wenn der Lauf startet. Verweigern schaltet das Netzwerk der Sandbox ab; Zulassen und Zuerst fragen lassen es an, und bei Zuerst fragen fragen web_fetch und web_search des Harness weiterhin bei jedem Aufruf. Solange das Netzwerk an ist, steht GitHub immer auf der Ausgangs-Zulassungsliste.

Prüfen, ob deine Agentenläufe in der Sandbox laufen

Zwei Dinge entscheiden das, beide auf dem Server: ob der Host ein Backend anbietet und ob --sandbox an ist. Prüfe sie in dieser Reihenfolge.

Öffne Einstellungen → Server → Diagnose und Datenschutz
Lies die Karte Sandboxing. Der Fakt Host ist der Rechner, auf dem cc_server läuft, nicht der Rechner, den du gerade ansiehst. Das Feld Backend nennt Native sandbox (Seatbelt unter macOS, bubblewrap unter Linux und WSL2) oder No isolation. Der Fakt Aktiv in Kraft ist die Einstellung dieses Geräts, nicht die Umhüllung, die der Server wirklich nutzt.
Lies das Startlog des Servers. Es schreibt genau eine von drei Zeilen:
- agent sandbox ON plus die Backend-Notiz — die Läufe sind umhüllt
- no OS-native agent sandbox on this host plus einen Installationshinweis, wo es einen gibt — die Läufe sind nicht umhüllt
- agent sandbox DISABLED by --sandbox off — ein bewusstes Abwählen

GET /healthz meldet den Sandbox-Zustand nicht, also ist das Startlog die Prüfung.

Um die Sandbox bewusst abzuschalten — der Grund dafür ist ein Host, auf dem das Profil sich falsch verhält —, startest du den Server mit --sandbox off oder setzt CC_SERVER_SANDBOX=off. Der Standard ist on, und on heißt „ein Backend nutzen, wenn der Host eines hat“, nie „eines verlangen“.

Zwei Situationen bekommen nie eine native Sandbox-Umhüllung. Unter Windows meldet die native Prüfung immer, dass keine verfügbar ist, und es gibt nichts zu installieren — die Agenten-Ausführung nutzt none. Das Backend microvm ist getrennt (interaktive Terminals und Rigs) und hängt an der Prüfung seiner eigenen Laufzeit. Unter Linux und WSL2 müssen bwrap und socat auf dem PATH liegen. Ohne sie meldet die Prüfung, dass keine verfügbar ist, und nennt die fehlenden Pakete.

Unter Linux/WSL2 mit installiertem bubblewrap lassen sich die Globs für Geheimnisdateien in der Standardrichtlinie nicht für Dateien durchsetzen, die ein Agent später anlegt. Ein solcher nativer Lauf scheitert jetzt, statt die Regeln still zu ignorieren. Eine positive Prüfung beim Start garantiert deshalb nicht, dass eine Ausführung unter Linux starten kann. --sandbox off ist ein bewusstes Abwählen ohne Einschränkung, kein Ersatz für eine Sicherheitsgrenze.

Wissen, was ein Modus schon verbietet

Der Modus ist je Bereich gespeichert und speist den Schutzregel-Resolver als Schicht Modus-Voreinstellung. Drei der vier Modi sind schreibgeschützt, und ein Nur-Lese-Modus verweigert elf Effektklassen rundweg:

Modus	Worktree	Von der Voreinstellung verweigert
Agent (`chat`)	Beschreibbar	Nichts — es gelten die eingebauten Vorgaben
Plan	Schreibgeschützt	Eine Datei löschen, außerhalb des Arbeitsbaums schreiben, einen Commit erstellen, zu einem Remote pushen, einen Pull Request öffnen, eine Review veröffentlichen oder mergen, in einen externen Tracker schreiben, ein Paket installieren, einen Prozess ausführen, Arbeitsbereichsstruktur ändern, eine Kapsel (Rig) steuern
Review	Schreibgeschützt	Dieselben elf. Nicht wählbar — der Composer bietet nur Agent, Plan und Orchestrate
Orchestrate	Schreibgeschützt	Dieselben elf

Auf das Netzwerk zugreifen und Ein Geheimnis lesen verweigert ein Nur-Lese-Modus absichtlich nicht: Recherche ist der Sinn eines solchen.

Eine Freigabe verlangen, bevor eine Aktion läuft

Eine Freigabe ist eine Entscheidung der Schutzregeln, keine Sandbox-Einstellung.

Öffne Einstellungen → Arbeitsbereich → Agent-Berechtigungen
Setze die Aktionsklasse auf Zuerst fragen, im Geltungsbereich Arbeitsbereich, Agent oder Bereich

Eine Entscheidung Zuerst fragen unterbricht den Lauf und fragt dich. Ohne verbundene zuständige Person fällt sie fail-closed aus, und die Aktion wird abgelehnt. Die volle Auflösungsreihenfolge steht unter Schutzregeln konfigurieren.

Fehlersuche

Ein Agent kann nicht pushen, obwohl ich es nie verweigert habe

Lies, was git ausgegeben hat. Control Center policy: … heißt, eine Regel hat den Push verweigert oder ein Zuerst fragen blieb unbeantwortet. … is not linked to this workspace heißt, der Push zielt auf ein Repo, das weder das eigene des Worktrees noch mit dem Arbeitsbereich verknüpft ist. Control Center has no GitHub credential that can push … heißt, die GitHub App ist auf diesem Repo nicht installiert und keine Ersatz-Zugangsdaten konnten pushen: Installiere die App dort oder verbinde GitHub.

Die Karte Sandboxing meldet keine native Sandbox

Dann sind die Agentenläufe auf diesem Host weder von Seatbelt noch von bubblewrap umhüllt, und die übrigen Grenzen sind das, was du hast. Unter Linux und WSL2 installierst du beide fehlenden Werkzeuge — sudo apt-get install bubblewrap socat — und startest den Server neu. Das Startlog sollte danach sagen, dass die Sandbox an ist. Unter Windows gibt es kein natives Backend zum Installieren, also verschärfe stattdessen die Schutzregeln. Siehe Schutzregeln konfigurieren.

Ein Agent hat eine Datei außerhalb seines Worktrees erreicht

Welches Werkzeug sie erreicht hat, entscheidet, ob das zu erwarten ist.

Die prozessinternen Dateiwerkzeuge des Harness (read, write, edit, apply patch, search, find, search_files) laufen im Serverprozess, also gilt für sie kein Sandbox-Profil — ihre Grenze sind die eigene Pfadbeschränkung und die Schutzregeln. Ein bash-Befehl oder die Claude-Code-CLI ist umhüllt, wo ein Backend existiert, und deine registrierten Checkouts sind in dieser Umhüllung in jedem Modus schreibgesperrt, einschließlich ihrer über den Symlink aufgelösten Schreibweisen (unter macOS löst sich ein Pfad über /tmp oder /var/folders unter /private auf, und beide Schreibweisen sind jetzt verboten). Auf einem Host ohne Backend gilt davon nichts. So oder so können die Schutzregeln Außerhalb des Arbeitsbaums schreiben rundweg verweigern.