Wie sicher ist die Claude Code Sandbox auf dem Mac?
Ein Blick unter die Haube von Claude Code und Cowork
KI-Agenten führen Befehle auf deinem Rechner aus — aber wie gut schützen dich die Sandboxes von Claude Code und Cowork? Beide versprechen Isolation, setzen aber auf unterschiedliche Mechanismen. Ich habe nicht nur die Dokumentation gelesen, sondern beide Systeme mit Linux-Tools von innen untersucht. Das Ergebnis: Die Isolation ist real, nachprüfbar und überraschend durchdacht.
„Falls sich Claude entscheidet, alle meine Dateien zu löschen: Halb so wild. Aber bitte nur innerhalb einer isolierten VM !“
Wer Claude Code im Terminal mit den Standardeinstellungen nutzt, kennt das: Viele Befehle benötigen eine Freigabe, bevor Claude Code sie ausführt.
Immer wieder muss man abwägen, ob der jeweilige Befehl in Ordnung geht oder nicht:
„Allow this? Allow once? Allow always?“
Ständig prüft man: Ist das ungefährlich oder könnte dieser Befehl zu Problemen führen? Cognitive Load durch Kommandozeilen lesen.
Im Grunde gibt es zwei extreme Ansätze: Entweder man prüft jede einzelne Freigabeanfrage selbst oder setzt auf die Option --dangerously-skip-permissions, wodurch alles erlaubt ist. Dazwischen gibt es viele Abstufungen. Man kann seine Permissions feingranular definieren, aber das ist fast genauso aufwendig.
Wie schön wäre es, wenn man einfach alles erlauben könnte und dennoch sicher sein könnte, dass nichts Unerwünschtes auf dem eigenen Rechner passiert. Dann könnte Agentic Coding ungebremst stattfinden und man käme schnell zu Ergebnissen.
Genau das verspricht ein isoliertes System, das abgeschirmt vom eigenen Computer läuft. So ein isoliertes System verringert den Blast Radius — also den Schaden, den ein fehlgeleiteter Befehl maximal anrichten kann — immens. Wenn etwas schief geht, startet man einfach neu und geht zum letzten stabilen Ausgangszustand zurück. Es gibt viele Möglichkeiten, das umzusetzen.
Eine davon ist der in Claude Code eingebaute /sandbox-Befehl. Er aktiviert eine Sandbox, die Claude Code auf OS-Ebene einschränkt — Dateizugriffe und Netzwerk. Man kann Commands automatisch laufen lassen, ohne jedes Mal zu bestätigen, weil die Sandbox begrenzt, was passieren kann. Aber wie sicher ist das wirklich?
Und dann gibt es noch Cowork in der Desktop-Variante der Claude-App. Cowork richtet sich eher an Wissensarbeiter, nicht direkt an Entwickler. Es darf auf Ordner zugreifen, Dateien erstellen und verändern, Pakete installieren — und das alles autonom. Auf den ersten Blick ist dabei nicht ersichtlich, wie die Absicherung funktioniert. Es gibt keinen /sandbox-Befehl, den man aktivieren müsste. Die Isolation passiert im Hintergrund.
Mich hat beides interessiert: Wie funktioniert die Sandbox in Claude Code? Und wie schützt mich Cowork davor, dass ungewollte Änderungen auf meinem Rechner passieren?
Dabei wollte ich mich nicht nur auf die Dokumentation verlassen, sondern ich habe beide Systeme von innen untersucht. Hier ist, was ich gefunden habe.
Zwei Produkte, zwei Zielgruppen, zwei Sicherheitsmodelle
Bevor ich in die Technik gehe, ein wichtiger Unterschied:
Claude Code ist ein Terminal-Tool für Entwickler. Es führt Befehle auf deinem Rechner aus — im selben Kontext, in dem du arbeitest. Die Sandbox muss manuell aktiviert werden (/sandbox), ist opt-in. Das ergibt Sinn: Entwickler brauchen möglichst wenig Einschränkungen, um produktiv zu sein. Sie wollen Befehle ausführen können, die eine restriktive Sandbox behindern würde. Aber mit vielen Rechten kommt viel Verantwortung. Man muss verstehen, was man abnickt.
Cowork ist Teil der Claude Desktop-App und richtet sich an Nutzer, die sich nicht mit der Kommandozeile auseinander setzen wollen. Wenn jemand Claude bittet, eine Excel-Tabelle aus fünf PDFs zu erstellen, erwartet er ein Ergebnis — nicht eine Diskussion über Dateiberechtigungen. Cowork muss daher stärker absichern, und zwar ohne dass der Nutzer das konfigurieren muss.
Das Ergebnis: Zwei unterschiedliche Isolationsmodelle für zwei unterschiedliche Risikoprofile.
Lass uns in die Details gehen.
Cowork: Ein Linux in deinem Mac
Cowork startet eine leichtgewichtige Linux-VM über Apples Virtualization.framework. Kein Container, sondern eine echte virtuelle Maschine mit eigenem Kernel.
Was sagt die VM über sich?
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"
$ uname -r
6.8.0-94-generic
$ uname -m
aarch64
$ nproc
4
$ free -h
total used free
Mem: 3.8Gi 564Mi 1.8Gi
Swap: 0B 0B 0B
$ df -h /
Filesystem Size Used Avail Use%
/dev/nvme0n1p1 9.6G 7.2G 2.4G 75%
Ubuntu 22.04 auf ARM64, 4 Kerne, 3,8 GB RAM, eine 10-GB-Disk. Kein Swap. Schlank genug für Dokumentenverarbeitung und Skripte, aber nicht für Machine-Learning-Training gedacht.
Auf dem macOS-Host finden sich die VM-Dateien unter ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/. Das Root-Image (rootfs.img) ist 10 GB groß als Sparse-Datei, belegt aber nur etwa 7,5 GB on-disk.
Daneben liegt ein komprimiertes Backup (rootfs.img.zst, ~2 GB) und ein paar Konfigurationsdateien: efivars.fd, macAddress, machineIdentifier.
Wie drei Schichten zusammen die Isolation absichern
Die VM allein wäre schon eine solide Grenze. Aber Anthropic stapelt drei Schichten übereinander.
Schicht 1: Die VM
Apples Virtualization.framework stellt Hardware-Isolation bereit. Der Gast hat seinen eigenen Kernel. Selbst ein rm -rf / in der VM lässt den Host unberührt.
Schicht 2: bubblewrap + seccomp
Innerhalb der VM läuft nicht direkt Claude, sondern erst bubblewrap (kurz: bwrap). Bubblewrap ist ein Sandboxing-Tool, das Linux-Namespaces nutzt, um Prozesse voneinander zu isolieren — ähnlich wie Container es tun, aber leichtgewichtiger.
Es schränkt ein, was ein Prozess sehen und tun darf: welche Dateien, welche Netzwerkschnittstellen, welche anderen Prozesse.
In der Cowork-VM ist bubblewrap PID 1, also der allererste Prozess:
$ cat /proc/1/status | head -2
Name: bwrap
State: S (sleeping)
Die bwrap-Kommandozeile (über /proc/1/cmdline auslesbar) zeigt die wichtigsten Einschränkungen im Überblick:
--unshare-net— eigener Netzwerk-Namespace, kein direkter Netzzugang--unshare-pid— eigener PID-Namespace, andere Prozesse unsichtbar--ro-bind / /— Root-Dateisystem read-only eingebunden--die-with-parent— stirbt der Elternprozess, stirbt die Sandbox mit--tmpfs /etc/ssh/ssh_config.d— SSH-Konfiguration wird mit einem leeren tmpfs überdeckt
Zusätzlich wird ein seccomp-Filter geladen. Seccomp (Secure Computing Mode) ist ein Mechanismus im Linux-Kernel, der festlegt, welche Systemaufrufe ein Prozess machen darf. Systemaufrufe sind die Schnittstelle zwischen einem Programm und dem Betriebssystem — Dateien öffnen, Netzwerkverbindungen herstellen, Prozesse starten.
Ein seccomp-Filter kann gezielt einzelne Systemaufrufe blockieren und damit den Aktionsradius eines Prozesses stark einschränken.
$ grep Seccomp /proc/self/status
Seccomp: 2
Seccomp_filters: 2
Seccomp: 2 bedeutet Filter-Modus — es gibt eine aktive Allowlist für erlaubte Syscalls. Die Filterdatei heißt unix-block.bpf und wird über eine eigene Binary (apply-seccomp) geladen.
Schicht 3: Netzwerk-Isolation
Kein Prozess in der Sandbox hat direkten Internetzugang. Aller Traffic geht durch einen lokalen Proxy:
$ env | grep HTTP_PROXY
HTTP_PROXY=http://localhost:3128
$ env | grep ALL_PROXY
ALL_PROXY=socks5h://localhost:1080
Der Proxy läuft über socat, das TCP-Verbindungen in Unix-Sockets tunnelt, die aus der VM herausführen. Auf der Host-Seite entscheidet eine Allowlist, welche Domains passieren dürfen.
Ich habe es getestet:
$ curl -s -o /dev/null -w "%{http_code}" https://registry.npmjs.org
200
$ curl -s -o /dev/null -w "%{http_code}" https://pypi.org
200
$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "HTTP/1.1"
< HTTP/1.1 403 Forbidden
$ curl -sv https://evil-exfiltration-test.example.org 2>&1 | grep "X-Proxy"
< X-Proxy-Error: blocked-by-allowlist
npm und PyPI kommen durch. Alles andere bekommt ein 403 Forbidden mit dem Header X-Proxy-Error: blocked-by-allowlist. Auch direkte DNS-Lookups scheitern:
$ nslookup google.com
socket(): Operation not permitted
;; no servers could be reached
Das ist konsequent: Selbst wenn ein Prompt-Injection-Angriff Claude dazu bringen würde, Daten an einen externen Server zu senden — der Proxy würde es blockieren.
Welche Dateien sieht die VM?
Dateien kommen über VirtioFS in die VM — ein Dateisystem-Protokoll, das speziell für die Kommunikation zwischen VM und Host entwickelt wurde. Statt echte Hardware zu simulieren, arbeiten Host und Guest bewusst zusammen (Paravirtualisierung). Das macht den Dateizugriff schnell und mit wenig Overhead möglich.
$ mount | grep virtiofs
/mnt/.virtiofs-root/shared/Work/.../Marketing on
/sessions/elegant-adoring-brown/mnt/Marketing type fuse (rw,...)
Nur der Ordner, den ich in der Desktop-App ausgewählt habe, wird gemountet. Nicht mein Home-Verzeichnis, nicht mein Desktop, nicht meine Downloads — nur der eine Ordner, den ich explizit freigegeben habe.
Plugins und Skills werden über bindfs zusätzlich eingebunden. Bindfs ist ein FUSE-Dateisystem, das einen vorhandenen Ordner an einer anderen Stelle nochmal einbindet — ähnlich wie ein Symlink, aber mit der Möglichkeit, die Berechtigungen zu ändern. So können Skills zum Beispiel read-only eingebunden werden, obwohl sie auf dem Host beschreibbar sind. Uploads landen ebenfalls in einem separaten, schreibgeschützten Mount.
Ein Detail verrät, dass die VM mehrere Conversations gleichzeitig bedient: Im /sessions/-Verzeichnis sitzen verschiedene Sessions nebeneinander:
$ ls -la /sessions/
drwxr-x--- elegant-adoring-brown elegant-adoring-brown ...
drwxr-x--- nobody nogroup awesome-epic-mccarthy
drwxr-x--- nobody nogroup dazzling-vibrant-carson
Jede Session bekommt einen eigenen Linux-User mit eigener UID. Mein User heißt elegant-adoring-brown (uid 1005). Die anderen Sessions sind unter nobody gelistet — ich kann ihre Dateien nicht lesen.
Wie schützt Claude Code ohne VM?
Claude Code im Terminal nutzt auf macOS einen anderen Ansatz: Apples Seatbelt (auch bekannt als sandbox-exec). Statt einer VM wird ein dynamisch generiertes Sandbox-Profil erstellt, das den Prozess auf OS-Ebene einschränkt. Wichtig: Die Sandbox muss manuell mit /sandbox aktiviert werden — ohne diesen Schritt läuft Claude Code ohne OS-Level-Isolation.
Das Profil startet mit (deny default) — alles ist verboten, außer es wird explizit erlaubt. Die Sandbox-Runtime ist Open Source und auf GitHub einsehbar. Ich habe das npm-Paket @anthropic-ai/sandbox-runtime heruntergeladen und die macos-sandbox-utils.js analysiert:
59 sysctl-Einträge werden zum Lesen freigegeben (Hardware-Info wie CPU-Anzahl, Speichergröße)
14 Mach-IPC-Services auf der Whitelist (Fonts, Logging, Security Server)
Mandatory Denies für
.env,.ssh,.aws,.git/hooks,.git/config— auch wenn das Arbeitsverzeichnis Schreibzugriff hatMove-Blocking:
file-write-renameundfile-write-unlinkwerden für geschützte Pfade blockiert, damit man die Denies nicht permvumgehen kann
Die Netzwerk-Isolation funktioniert genauso wie bei Cowork: Aller Traffic geht durch denselben Proxy mit Allowlist. Der Unterschied: Bei Seatbelt passiert das auf Prozess-Ebene (gleicher Kernel), bei Cowork auf VM-Ebene (eigener Kernel).
Warum zwei Modelle?
Claude Code richtet sich an Entwickler, die im Terminal schnelles Feedback brauchen. Der Seatbelt-Overhead liegt im niedrigen einstelligen Millisekundenbereich — ich habe es auf dem Host gemessen, kein spürbarer Unterschied zu einem Befehl ohne Sandbox. Entwickler können die Sandbox gezielt aktivieren, wenn sie einem Agenten mehr Autonomie geben wollen, ohne jeden Befehl freigeben zu müssen.
Cowork gibt Claude deutlich mehr Autonomie: Es läuft länger, erstellt eigenständig Dateien, installiert Pakete. Und es richtet sich an Nutzer, die nicht einschätzen können (und nicht einschätzen müssen), welche Befehle auf Betriebssystemebene ausgeführt werden. Der mögliche Schaden eines Agenten mit lokalem Dateizugriff, Codegenerierung und Netzwerk-Egress ist größer — und die Nutzer können ihn schlechter einschätzen. Die volle VM-Isolation ist hier angemessen.
Was ich daraus mitnehme
Die Isolation ist real. Nicht nur auf dem Papier, sondern nachprüfbar.
Drei Dinge haben mich besonders überzeugt:
Erstens die Proxy-Allowlist mit dem expliziten X-Proxy-Error: blocked-by-allowlist Header. Das ist keine stille Fehlermeldung, sondern eine bewusste Architekturentscheidung. Man sieht sofort, warum eine Verbindung scheitert.
Zweitens die Schichtung. VM allein wäre gut. Mit bubblewrap und seccomp wird’s besser. Alle drei zusammen machen es deutlich schwieriger, aus der Sandbox auszubrechen. Ein Exploit müsste gleichzeitig den seccomp-Filter umgehen, aus dem bwrap-Namespace ausbrechen und dann noch aus der VM raus — auf einem System, das keinen direkten Netzzugang hat.
Drittens die Transparenz. Die Sandbox-Runtime ist Open Source. Ich habe den Code der macos-sandbox-utils.js heruntergeladen — dort stehen die 59 sysctl-Einträge, die 14 Mach-Services und die Mandatory Denies für .env, .ssh und .aws schwarz auf weiß. Das Seatbelt-Profil wird dynamisch generiert, aber der generierende Code ist einsehbar. Die VM-Architektur lässt sich von innen inspizieren. Man muss niemandem glauben — man kann nachschauen.
Wer selbst nachschauen will: Die Sandbox-Runtime liegt auf GitHub. Ein npm pack und ein Blick in macos-sandbox-utils.js reichen, um das Seatbelt-Profil zu verstehen.
Was du jetzt tun kannst
Wenn du Claude Code nutzt und die Sandbox noch nicht ausprobiert hast: Starte eine Session und tippe /sandbox. Allein das reduziert den Aufwand, Befehle einzeln freizugeben, erheblich. Für den Alltag reicht das oft schon.
Wenn du tiefer einsteigen willst:
Sandbox-Runtime inspizieren:
npm pack @anthropic-ai/sandbox-runtime, entpacken,macos-sandbox-utils.jslesen. Dort siehst du exakt, was erlaubt und was blockiert wird.Cowork von innen ansehen: Starte Cowork und bitte es
cat /proc/1/cmdline | tr '\0' '\n'auszuführen. Die bubblewrap-Flags verraten dir die Isolation im Detail.Netzwerk testen: Ein
curl https://evil-exfiltration-test.example.orgin der Sandbox zeigt dir sofort, ob die Allowlist greift.
Wie geht es weiter?
Damit ist der Ist-Zustand klar. Aber eine Frage bleibt: Wird das so bleiben? Claude Code und Cowork teilen sich bereits die agentic Architektur — und es gibt konkrete Signale, dass auch die Sicherheitsmodelle zusammenwachsen:
Docker liefert mit
docker-model-runnerMicroVM-Sandboxes, die speziell für KI-Agenten gedacht sind.Apple bringt mit macOS 26 ein eigenes Containerization-Framework — erstmals native Container-Unterstützung auf dem Mac.
Anthropic dokumentiert DevContainer als offiziellen Weg für stärkere Isolation in Claude Code.
Drei Player, drei Ansätze, ein Ziel: Agenten sollen mehr dürfen, ohne mehr Schaden anrichten zu können. Im nächsten Artikel werde ich mir anschauen, was für und gegen jeden dieser Pfade spricht — und warum ich einen davon für den wahrscheinlichsten halte.
Wenn du benachrichtigt werden willst, wenn der nächste Artikel veröffentlich ist:
Quellen
Inside Claude Cowork (Pedro José Pereira Vieito) — Reverse-Engineering-Analyse der VM-Architektur