Claude-Code-Sandbox konfigurieren: Leitfaden 2026

Claude Code sollte in einem unbekannten Repository zunächst nur im Planmodus oder mit einzeln bestätigten Aktionen laufen; sobald Abhängigkeiten installiert, externe Netzwerke geöffnet oder lange Agent-Aufgaben ausgeführt werden, ist eine eigens dafür vorgesehene virtuelle Maschine oder unabhängige Cloud-Mac-Umgebung die bessere Wahl. Die Claude-Code-Sandbox-Konfiguration 2026 muss dabei drei Grenzen gleichzeitig setzen: Dateisystem, Netzwerk und Berechtigungen.

Letzte Aktualisierung: 15.08.2026. Die technischen Angaben wurden anhand der offiziellen Anthropic-Dokumentation, der Anthropic-Sicherheitsveröffentlichungen, der offiziellen Claude-Code-Sicherheitsmeldungen und der ursprünglichen Wiz-Forschung geprüft.

Dieser Leitfaden richtet sich an Entwickler, die Open-Source-Projekte oder fremde Pull Requests mit Claude Code untersuchen, an technische Verantwortliche, die Tests, Abhängigkeitsinstallationen und MCP-Aufrufe begrenzen müssen, sowie an Administratoren, die einen isolierten Cloud-Mac als Ausführungsrechner für AI Agents vorbereiten.

Das eigentliche Risiko vor dem ersten Start

Ein häufiger Fehlstart sieht unspektakulär aus: Ein Repository wird geklont, das Terminal wechselt in das Projektverzeichnis und Claude Code wird unmittelbar gestartet. Der Entwickler erwartet eine Analyse. Tatsächlich können bereits projektgesteuerte Einstellungen, Hooks, Installationsskripte, symbolische Verknüpfungen oder manipulierte Tool-Ausgaben Einfluss darauf nehmen, welche Informationen gelesen und welche Aktionen vorbereitet werden.

Das Risiko stammt deshalb nicht ausschließlich aus einem von Claude Code erzeugten Shell-Befehl. Auch die Umgebung, in der der Agent startet, kann Anweisungen oder Konfigurationen enthalten, die vor einer bewussten Vertrauensentscheidung verarbeitet werden. Anthropic dokumentierte im Januar 2026 eine Schwachstelle, bei der eine bösartige Repository-Konfiguration vor der Vertrauensbestätigung Daten einschließlich API-Schlüsseln an einen kontrollierten Endpunkt senden konnte. Die betroffenen Versionen lagen unter 2.0.65; die veröffentlichte Korrektur war Version 2.0.65. (offizielle Claude-Code-Sicherheitsmeldung)

Wiz beschrieb am 16.07.2026 außerdem die als „GhostApproval“ bezeichnete Forschung zu Trust-Boundary-Problemen mit symbolischen Verknüpfungen und vom Repository gesteuerten Inhalten. Die Untersuchung wurde von Wiz veröffentlicht; Anthropic bestätigte gegenüber Wiz eine Behebung für die betroffenen Abläufe, stellte aber zugleich klar, dass das untersuchte Szenario eine ausdrückliche Bestätigung innerhalb eines Verzeichnisses mit einer manipulierten symbolischen Verknüpfung voraussetzte und außerhalb des vorgesehenen Bedrohungsmodells lag. Das ist ein konkreter Forschungsbefund, kein Beleg dafür, dass jede Claude-Code-Version und jedes Repository ausnahmslos ausnutzbar sind. (ursprüngliche GhostApproval-Forschung von Wiz)

Achtung: Eine Vertrauensabfrage beantwortet nur die Frage, ob eine Aktion freigegeben wird. Sie ersetzt keine Betriebssystem-Isolation und verhindert nicht automatisch, dass bereits geladene Projektkonfigurationen, Hooks oder externe Tool-Ausgaben die Entscheidungsgrundlage beeinflussen.

Die erste Entscheidung lautet daher: Wenn Herkunft, Einstellungen und Installationslogik eines Repositories nicht überprüft wurden, darf der erste Lauf nicht in einer Umgebung stattfinden, die gleichzeitig private SSH-Schlüssel, Cloud-Zugangsdaten, Signaturmaterial und Produktionsvariablen enthält.

Die Vorprüfung mit einem sauberen Ausgangspunkt

Vor dem Start von Claude Code sollte das Repository zunächst ohne Agenten und ohne Ausführung fremder Installationsbefehle untersucht werden. Ziel ist nicht, jede Sicherheitsgefahr zu beweisen, sondern die Zahl unbekannter Eingriffspunkte zu reduzieren.

1. Repository-Inhalt getrennt prüfen

Die erste Prüfung erfolgt idealerweise in einem frischen Arbeitsverzeichnis mit deaktivierter Ausführung von Projekt-Hooks. Dabei werden insbesondere folgende Bereiche kontrolliert:

• .claude/ und projektbezogene settings.json-Dateien;
• CLAUDE.md und weitere Agent- oder Automatisierungsanweisungen;
• package.json, package-lock.json, pnpm-lock.yaml, Makefile, Taskfile und Build-Skripte;
• Dockerfile, .devcontainer/ und Container-Entrypoints;
• Git-Hooks, CI/CD-Dateien und Installationsskripte;
• MCP-Konfigurationen mit lokalen Befehlen oder externen Endpunkten;
• symbolische Verknüpfungen, insbesondere auf Home-Verzeichnisse, Konfigurationsordner oder gemountete Arbeitsbereiche;
• ungewöhnliche externe URLs, Download-Quellen und Shell-Aufrufe.

Anthropic weist darauf hin, dass MCP-Server von Drittanbietern nicht pauschal verifiziert oder auditiert werden. Ein MCP-Eintrag ist deshalb nicht nur eine Komfortfunktion, sondern ein zusätzlicher Vertrauensbereich mit eigenen Prozessen, Netzwerkverbindungen und möglicherweise Dateirechten. (offizielle MCP-Dokumentation von Anthropic)

2. Zugangsdaten aus dem Ausführungsbereich entfernen

Vor dem ersten interaktiven Lauf sollten private Schlüssel und langlebige Tokens nicht im Arbeitsbereich oder in automatisch erreichbaren Standardpfaden liegen. Das betrifft insbesondere:

• private SSH-Schlüssel und SSH-Agent-Sockets;
• Cloud-Anmeldedaten und lokale Credential-Dateien;
• Codesigning-Zertifikate und Notarisierungsdaten;
• Produktionsvariablen in Shell-Profilen;
• Zugangsdaten für Paketregister, Datenbanken und Deployment-Systeme;
• Browserprofile oder lokale Konfigurationsdateien mit Sitzungsinformationen.

Die praktische Leitlinie ist einfach: Was Claude Code nicht lesen kann, kann ein kompromittierter Prozess nicht direkt aus dem Arbeitsbereich heraus exfiltrieren. Anthropic beschreibt genau dieses Prinzip in der eigenen Containment-Dokumentation: Zugangsdaten sollen außerhalb der Sandbox bleiben, weil eine erfolgreiche Manipulation sonst nicht automatisch den Zugriff auf diese Daten verhindert. (Anthropic-Dokumentation zur Agenten-Eindämmung)

Die erste Claude-Code-Sitzung mit minimalen Rechten

Nach der statischen Vorprüfung beginnt Claude Code nicht mit automatischer Ausführung, sondern mit einer lesenden Analyse. Der Planmodus ist dafür der passende Einstieg: Claude Code darf den Bestand untersuchen und einen Vorschlag ausarbeiten, soll aber weder Dateien ändern noch Shell-Befehle ausführen. Die CLI-Dokumentation führt --permission-mode plan als verfügbaren Startmodus auf; --dangerously-skip-permissions überspringt dagegen die Berechtigungsabfragen und ist für unbekannte Inhalte kein vertretbarer Standard. (offizielle Claude-Code-CLI-Dokumentation)

Ist Claude Code in einem unbekannten GitHub-Repository sicher?
Nicht automatisch. Ein öffentliches Repository ist nicht dasselbe wie ein vertrauenswürdiges Repository. Entscheidend sind Maintainer, Änderungsverlauf, Projektkonfiguration, Abhängigkeiten, Hooks, symbolische Verknüpfungen und die Daten, die in der laufenden Umgebung erreichbar sind. Für eine reine Codelektüre ist ein eingeschränkter lokaler Lauf möglich; für Installationen, Netzwerkzugriffe oder lange autonome Aufgaben sollte das Repository in eine stärker isolierte Umgebung wechseln.

3. Planmodus und Einzelbestätigung

Für den ersten Durchgang empfiehlt sich folgende Reihenfolge:

1. Arbeitsverzeichnis in einen frischen Pfad kopieren oder neu klonen.
2. Claude Code mit --permission-mode plan starten.
3. Nur nach Konfigurationsdateien, Hooks, Abhängigkeiten und Netzwerkzielen suchen lassen.
4. Den erzeugten Plan außerhalb des Agentenprozesses prüfen.
5. Erst danach einzelne Lese-, Test- oder Schreibaktionen freigeben.
6. Jede dauerhafte Erlaubnis auf ein konkretes Werkzeug, Verzeichnis oder Kommandomuster begrenzen.

Die Berechtigungsregeln unterscheiden grundsätzlich zwischen deny, ask und allow. Verweigerungsregeln haben Vorrang vor Erlaubnisregeln; eine breite allow-Regel kann daher nicht als Ersatz für präzise Pfad- und Befehlsgrenzen dienen. Die offiziellen Berechtigungsunterlagen nennen außerdem unterschiedliche Ebenen für Organisationsrichtlinien, Kommandozeilenargumente, lokale Projektdateien und Benutzereinstellungen. (offizielle Berechtigungsdokumentation von Anthropic)

Die macOS-Seatbelt-Grenzen für Dateien und Prozesse

Die Claude-Code-Sandbox nutzt auf macOS die Betriebssystemfunktion Seatbelt, um Bash und dessen Unterprozesse zu begrenzen. Anthropic beschreibt zwei zentrale Kontrollflächen: Dateisystem-Isolation und Netzwerk-Isolation. Im vorgesehenen Arbeitsbereich können Lese- und Schreibvorgänge erlaubt werden, während Zugriffe außerhalb definierter Pfade blockiert oder zur Bestätigung vorgelegt werden. Für Netzwerkzugriffe kann ein Proxy die erlaubten Ziele kontrollieren; nicht freigegebene Domains sollen nicht stillschweigend erreichbar sein. (offizielle Erklärung zur Claude-Code-Sandbox)

Wichtig ist die Reichweite: Die Einschränkung betrifft nicht nur den unmittelbar von Claude Code gestarteten Befehl, sondern auch Skripte, Programme und Unterprozesse, die dieser Befehl erzeugt. Das macht Seatbelt wesentlich stärker als eine reine Regel im Prompt oder eine Anweisung in CLAUDE.md.

Kann die Claude-Code-Sandbox SSH-Schlüssel schützen?
Sie kann das Risiko deutlich begrenzen, wenn die Schlüssel außerhalb der erlaubten Dateipfade liegen und der Netzwerkzugang ebenfalls eingeschränkt ist. Sie ist aber kein Versprechen, dass jeder Schlüssel auf dem Host unter allen Umständen geschützt bleibt. Anthropic betont selbst, dass Datei- und Netzwerkgrenzen zusammengehören: Ohne Dateisystemschutz können sensible Dateien gelesen werden; ohne Netzwerkisolation könnten gelesene Daten abfließen. (Anthropic-Dokumentation zu Sandbox-Grenzen)

Die Konfiguration sollte deshalb mindestens folgende Regeln enthalten:

• Arbeitsverzeichnis als einzigen normalen Schreibbereich definieren;
• ~/.ssh, Cloud-Credential-Verzeichnisse und Signaturmaterial explizit verweigern;
• zusätzliche Arbeitsverzeichnisse nur bei dokumentiertem Bedarf hinzufügen;
• Netzwerkzugriffe zunächst blockieren;
• erforderliche Domains einzeln freigeben;
• Shell-Kommandos außerhalb des Sandbox-Bereichs weiterhin bestätigen lassen;
• bei nicht verfügbarer Sandbox nicht still auf einen ungeschützten Modus wechseln.

Anthropic meldete im Jahr 2026 mehrere Claude-Code-Sicherheitsprobleme, unter anderem zu Git-Worktrees, symbolischen Verknüpfungen und Trust-Dialogen. Diese Meldungen sind ein weiterer Grund, die installierte Version aktuell zu halten und die offiziellen Sicherheitsmeldungen regelmäßig zu prüfen, statt eine einmal funktionierende Regelkonfiguration als dauerhaft ausreichend zu betrachten.

Die Netzwerkfreigabe mit einer kleinen Whitelist

Ein unbekanntes Projekt benötigt für eine reine Analyse oft gar keinen Internetzugang. Für Tests oder Abhängigkeitsinstallationen kann er später erforderlich sein, aber diese Notwendigkeit sollte erst nach der Quellcodeprüfung entstehen.

Wie lassen sich Netzwerkdomänen und Dateizugriffe in Claude Code begrenzen?
Die Einschränkung wird nicht durch eine einzelne Bestätigungsfrage erreicht, sondern durch das Zusammenspiel aus Sandbox-Regeln, Berechtigungen und gegebenenfalls einem Unternehmensproxy. Anthropic nennt für eingeschränkte Umgebungen unter anderem API-Endpunkte und Telemetriedienste, die für den normalen Betrieb erreichbar sein können; in einer Organisation sollten diese Ziele über die eigene Proxy- oder Firewall-Policy geprüft und nicht unkritisch aus einer Beispielkonfiguration übernommen werden. (offizielle Dokumentation zum Unternehmensproxy)

Eine häufige Fehlentscheidung besteht darin, ein einzelnes fehlgeschlagenes Kommando dauerhaft zu erlauben, weil ein Paketmanager oder Testwerkzeug sonst nicht funktioniert. Besser ist es, die Ursache zu prüfen: Benötigt das Kommando tatsächlich Internetzugriff, versucht es nur einen nicht vorhandenen Pfad zu verwenden oder fordert es Zugriff auf einen Bereich an, der absichtlich geschützt bleiben sollte?

Erfahrung aus der Praxis: Eine Kompatibilitätsstörung ist kein Sicherheitsargument. Wenn ein Tool nur funktioniert, sobald der gesamte Home-Bereich oder das gesamte Internet freigegeben wird, ist die Ausführungsumgebung für diesen Task noch nicht ausreichend abgegrenzt.

Dev Container, virtuelle Maschine und Cloud-Mac

Kann ein Dev Container Claude Code vollständig isolieren?
Nein. Ein Dev Container verbessert die Trennung von Abhängigkeiten, Arbeitsverzeichnis und Entwicklungswerkzeugen, ist aber nicht automatisch eine vollständige Sicherheitsgrenze. Der Container hängt weiterhin von Host-Kernel, Mounts, Docker-Socket, Netzwerkmodus, Umgebungsvariablen und lokalen Volumes ab. Anthropic empfiehlt Dev Container als zusätzliche Isolation, beschreibt für stärker autonome Agenten jedoch auch Container-, VM- und Egress-Kontrollen als getrennte Muster. (offizielle Sicherheitsdokumentation für Claude Code)

Die Auswahl sollte anhand des Risikos erfolgen:

• Lokale Claude-Code-Sandbox: geeignet für bekannte Repositories, lesende Analyse und klar begrenzte Tests.
• Dev Container: geeignet, wenn reproduzierbare Toolchains und getrennte Abhängigkeiten benötigt werden, der Host aber weiterhin sorgfältig geschützt ist.
• Virtuelle Maschine: geeignet für unbekannte Installationsskripte, weitreichende Systemtests oder längere Agent-Aufgaben.
• Unabhängiger Cloud-Mac: geeignet, wenn macOS-Werkzeuge, Xcode-nahe Toolchains, GUI-Anwendungen oder eine entfernte, getrennt verwaltete Arbeitsumgebung erforderlich sind.

Die zentrale Frage lautet nicht, ob eine Umgebung „sicher“ klingt, sondern wie groß der verbleibende Explosionsradius ist. Ein Cloud-Mac ist nicht von selbst sicher: Fehlende Netzwerkregeln, dauerhaft hinterlegte Zugangsdaten oder ein gemeinsam genutzter Arbeitsbereich können auch dort Risiken erzeugen.

Wenn die Ausführung macOS-spezifische Werkzeuge benötigt und der persönliche Rechner nicht belastet werden soll, kann eine getrennte Mietumgebung sinnvoll sein. Die verfügbaren Optionen und den aktuellen Bestellweg sollte der Verantwortliche vorab auf der deutschen RUVCLOUD-Übersicht prüfen. Für einen einmaligen Test ist eine kurze, klar begrenzte Laufzeit meist leichter zu kontrollieren als ein dauerhaft zugänglicher Entwicklungsrechner.

Die Ausführung mit einem überprüfbaren Ablauf

Für einen ersten ausführbaren Durchgang bietet sich diese Reihenfolge an:

4. Arbeitsbereich vorbereiten

Ein neues Verzeichnis anlegen, das Repository dort klonen und keine persönlichen Konfigurationsdateien hinein kopieren. Ein separates Git-Remote oder ein eingeschränkter Branch verhindert, dass ein unüberprüfter Agent versehentlich Produktionscode überschreibt.

5. Konfiguration und MCP prüfen

Vor dem Start von Claude Code alle projektbezogenen Einstellungen, Hooks und MCP-Definitionen lesen. Nicht benötigte MCP-Server entfernen oder deaktivieren. Für jeden verbleibenden Server dokumentieren, welche Dateien, Befehle und Netzwerkziele er benötigt.

6. Planmodus ausführen

Die Aufgabe zunächst auf Inventarisierung begrenzen: Build-System, Abhängigkeiten, Testbefehle, externe Dienste und mögliche Geheimnisquellen erfassen. Es sollten keine Installationsbefehle und keine Änderungen außerhalb des Arbeitsbereichs zugelassen werden.

7. Sandbox und Berechtigungen aktivieren

Die Datei- und Netzwerkgrenzen festlegen, sensible Pfade verweigern und Shell sowie MCP standardmäßig auf ask setzen. Erst nach einer Prüfung des Plans dürfen einzelne Werkzeuge freigegeben werden.

8. Abhängigkeiten getrennt installieren

Wenn eine Installation erforderlich ist, sollte der Befehl zunächst manuell geprüft und mit minimalem Netzwerkzugriff ausgeführt werden. Paketmanager-Skripte dürfen nicht allein deshalb vertraut werden, weil sie aus einem bekannten Ökosystem stammen.

9. Langlaufende Aufgaben nicht auf dem Hauptsystem belassen

Dauert ein Agent-Lauf länger, benötigt er mehrere externe Dienste oder soll er unbeaufsichtigt Tests und Reparaturen durchführen, sollte der Prozess in eine VM oder einen unabhängigen Cloud-Mac wechseln. Zugangsdaten werden dort nicht dauerhaft gespeichert, sondern über kurzlebige Tokens, eingeschränkte Proxys oder kontrollierte Übergaben bereitgestellt.

Die Abschlussprüfung und der sichere Rückbau

Nach der Aufgabe ist der Zustand des Systems wichtiger als die letzte erfolgreiche Testausgabe. Ein sauberer Git-Diff zeigt nur Änderungen am Repository; er beweist nicht, dass keine externen Nebenwirkungen eingetreten sind.

Die Abschlusskontrolle sollte mindestens diese Punkte abdecken:

• git diff und nicht versionierte Dateien prüfen;
• neue Shell-Profile, Cron-Einträge, LaunchAgents und lokale Hooks suchen;
• authorized_keys, bekannte SSH-Dateien und Agent-Sockets kontrollieren;
• verwendete Tokens und Cloud-Zugangsdaten widerrufen oder rotieren;
• ungewöhnliche Netzwerkziele und Proxy-Protokolle untersuchen;
• lokale Paket- und Build-Artefakte bewerten;
• MCP-Konfigurationen und neu erzeugte Konfigurationsdateien entfernen;
• Änderungen an externen Diensten getrennt von Codeänderungen dokumentieren.

Soll Claude Code auf dem Haupt-Mac oder in einer virtuellen Maschine laufen?
Auf dem Haupt-Mac ist ein kontrollierter Lauf vertretbar, wenn das Repository bekannt ist, keine sensiblen Zugangsdaten erreichbar sind, die Sandbox aktiv bleibt und keine weitreichenden Installationen vorgesehen sind. Eine VM ist die bessere Wahl, wenn Herkunft und Konfiguration unklar sind, der Agent lange unbeaufsichtigt laufen soll oder Installationsskripte, Netzwerkzugriffe und Systemwerkzeuge zusammenkommen.

Die abschließende Entscheidung kann als einfache Bedingungsliste formuliert werden:

• Wenn das Repository bekannt ist, dann lokale Sandbox mit Planmodus und begrenzten Freigaben verwenden.
• Wenn nur reproduzierbare Entwicklungsabhängigkeiten getrennt werden müssen, dann Dev Container einsetzen, aber privilegierte Mounts und Host-Credentials vermeiden.
• Wenn Installationsskripte oder Systemänderungen erforderlich sind, dann eine Wegwerf-VM verwenden.
• Wenn zusätzlich macOS-Werkzeuge, lange Agent-Aufgaben oder ein entfernter Ausführungsort benötigt werden, dann einen unabhängigen Cloud-Mac bereitstellen.
• Wenn Dateien, Netzwerkziele oder Zugangsdaten nicht klar begrenzt werden können, dann die Ausführung abbrechen und die Umgebung nicht weiter vertrauen.

Für einmalige oder wiederkehrende Agent-Aufgaben sollte ein Cloud-Mac nicht einfach als dauerhafte Arbeitsstation behandelt werden. Sinnvoller sind ein definierter Startzustand, getrennte Zugangsdaten, dokumentierte Netzwerkregeln und ein verlässlicher Rückbau. Die aktuellen Miet- und Bestelloptionen können auf der RUVCLOUD-Seite für Mac-Umgebungen geprüft werden; eine Buchung ist jedoch erst dann sinnvoll, wenn die benötigten Datei-, Netzwerk- und macOS-Grenzen feststehen.

Die passende Umgebung statt der bequemsten Freigabe

Die lokale Claude-Code-Sandbox ist für bekannte Projekte und kurze, kontrollierte Aufgaben effizient, aber sie schützt nicht automatisch vor einer schlecht konfigurierten Host-Umgebung. Ein Dev Container trennt Abhängigkeiten, nicht zwingend alle Host-Ressourcen. Eine VM oder ein unabhängiger Cloud-Mac vergrößert den Verwaltungsaufwand, verkleinert dafür den Schaden, wenn ein unbekanntes Skript, ein manipuliertes Repository oder ein überprivilegierter MCP-Server seine Grenzen überschreitet.

Der eigentliche Nachteil des bisherigen Haupt-Mac-Ansatzes liegt meist in drei Punkten: persönliche SSH- und Cloud-Zugangsdaten befinden sich zu nah am Arbeitsbereich, langfristig laufende Agenten bleiben auf einem Rechner mit weiteren privaten Daten aktiv, und die Wiederherstellung nach einer verdächtigen Ausführung wird manuell sowie schwer überprüfbar. Eine isolierte RUVCLOUD-Umgebung ist deshalb dann die bessere praktische Lösung, wenn sie als temporärer Ausführungsknoten mit getrennten Zugangsdaten, begrenztem Netzwerk und anschließendem Neuaufbau eingesetzt wird, nicht als angeblich automatisch sichere Umgebung. Insbesondere bei unbekannten Repositories sollte zuerst die Isolation festgelegt und erst danach der Cloud-Mac gemietet werden.