Was passiert, wenn man Claude in eine macOS-Sandbox sperrt?

Ist dir schon mal aufgefallen, dass alle Entwicklungsumgebungen und KI-Apps auf macOS ohne Sandbox ausgeführt werden? Das ist verständlich, denn als Entwickler oder KI will man möglichst viel Zugriff auf alle Daten haben. Aber darunter sind auch schützenswerte Daten, zuallererst die geheimen Schlüssel deiner SSH-Zugänge, aber auch Kundendaten oder einfach nur deine E-Mails, Fotos und Dokumente.

Apple hat genau dafür die systemeigene Sandbox eingeführt. Sie trägt den Codenamen “Seatbelt” und ist auf der Kommandozeile als sandbox-exec bekannt. Sie existiert schon seit vielen Jahren und ist Voraussetzung für alle Apps, die über Apples App Store vertrieben werden. Wäre es nicht gut, wenn Tools wie Claude (Anthropic), Gemini (Google), Copilot (GitHub), Codex (OpenAI) etc. in einer maßgeschneiderten Sandbox laufen könnten?

Ich habe das ausprobiert. Dabei ist eine App herausgekommen, und nebenbei ein paar Erkenntnisse darüber, wie sich eine KI verhält, wenn man ihr etwas verbietet.

Claude, der raffinierte Ausbrecher

Während der Entwicklung ist mir aufgefallen, dass Claude lokal ein kleiner raffinierter Ausbrecher ist. Wenn er auf irgendeine Datei nicht zugreifen konnte, hat er es über das Git-Repository versucht. Er nutzte auch verschiedene andere Tools, um irgendwie an die Inhalte zu kommen: Symlinks, Umwege über /tmp, im Zweifel auch mal sudo.

Allerdings ist Claude in den aktuelleren Versionen deutlich zurückhaltender geworden und man muss ihn etwas mehr überreden, sich die Informationen auf andere Art und Weise zu besorgen.

Hier ein Beispiel: Im ersten Anlauf gibt es keinerlei Schutz, Claude findet die Datei colors.txt per grep und liest sie einfach. Danach wird die Datei durch die Sandbox geschützt. Claude versucht es nun mit abgeschalteter eigener Sandbox von Claude Code, was ebenfalls scheitert, und diagnostiziert dann eine fehlende Datenschutz-Freigabe von macOS (TCC), die ich in den Systemeinstellungen erteilen solle. Erst auf meine Nachfrage “Maybe it is in the version control?” greift er zu Git: Der Inhalt war auch eingecheckt, und das .git-Verzeichnis war in diesem Beispiel nicht geschützt. Sein Kommentar dazu: “bypassing the filesystem-level TCC block entirely”.

Claude macht das nicht aus Bosheit. Er sieht eine Fehlermeldung, hält sie für ein Problem und will es lösen. Als Assistent ist das eine gute Eigenschaft, in einer Sandbox ist es anstrengend.

Jedenfalls reicht es nicht, nur die Verzeichnisse zu schützen. Man muss auch überlegen, ob es andere Wege gibt, wie auf die Daten zugegriffen werden kann.

Was ich dabei gelernt habe

Die Sandbox-Konfiguration muss selbst geschützt sein. Das klingt banal, ist aber der wichtigste Punkt: Wenn die KI die Regeln oder die Ignore-Dateien ändern kann, kann sie sich die Sandbox auch selbst öffnen. Diese Dateien müssen ohne Schreibzugriff eingebunden werden.

Der Papierkorb ist ein Datenspeicher. Auch dort können noch relevante Informationen liegen. Ist er gesperrt, legt die KI einfach eigene .Trash-Verzeichnisse innerhalb des Projekts an.

Die KI hat ein Gedächtnis. Claude legt in ~/.claude Protokolle jeder Sitzung ab, und darin landen auch die Inhalte aller Dateien, die er gelesen hat. Soll also Projekt A nichts von Projekt B wissen, ist auch das zu bedenken.

Sag ihr, dass sie in einer Sandbox ist. Damit die KI nicht besonders viele Versuche unternimmt, die Sandbox zu umgehen, kann man ihr von vornherein sagen, dass sie sich in einer befindet und sich entsprechend konstruktiv verhalten soll. Seitdem steht in meiner CLAUDE.md unter anderem:

“Operation not permitted” und EPERM auf einem Pfad sind Entscheidungen der Richtlinie, keine Bugs. Debugge den Code nicht deswegen. Nenne den Pfad.

Umgehe die Sandbox niemals. Kein sudo, keine Symlinks oder Umwege über /tmp um einen geschlossenen Ordner herum. Wenn Zugriff fehlt, sag genau, welche Zeile in welcher Datei ihn erlauben würde, und mach mit dem Teil der Aufgabe weiter, der ohne funktioniert.

Das wirkt. Statt zu tricksen sagt Claude jetzt: “Auf ~/.ssh habe ich keinen Zugriff, RO: ~/.ssh würde das ändern”, und macht dann mit dem Rest weiter.

Man muss sehen können, was passiert. Eine Sandbox, die nur stumm blockiert, ist frustrierend, weil Tools dann einfach nicht funktionieren und man nicht weiß, warum. Ich wollte deshalb zwei Dinge: vor dem Start sehen, welche Dateien die Regeln genau betreffen, und nachher sehen, welche Zugriffe abgewiesen wurden.

Bequemer Schutz durch BX

Aus alldem ist die BX macOS App entstanden. BX ist eine komfortable macOS-App, mit der sich Desktop-Apps und Entwicklungsumgebungen genauso in eine Sandbox legen lassen wie die sogenannten Harnesses der KIs, die direkt im Terminal gestartet werden.

Es ist einfach, Regeln aufzustellen, auf welche Dateien noch zugegriffen werden darf und welche nicht. Dabei können auch Patterns und Wildcards benutzt werden. Ebenso ist es möglich, bestimmte Dateien auf Read-Only zu stellen, sodass sie zwar gelesen, aber nicht geändert werden können.

Noch vor der Ausführung kann man in einem einfachen Interface, das an die Finder-Ansicht erinnert, sehen, welche Dateien die Regeln genau betreffen. Scheitert ein Tool, markiert BX die abgewiesenen Zugriffe genau an ihrer Stelle im Baum.

Die Regeln können aber auch direkt im Dateisystem abgelegt werden, über eine Ignore-Datei mit dem Namen .bxignore, die im Prinzip genauso funktioniert wie eine .gitignore. Und den Hinweistext für die KI erzeugt bx prompt gleich mit.

Warum nicht einfach Docker oder ein Devcontainer? Weil ich meine Apps nativ benutzen will, mit ihrem User Interface, den Einstellungen, den Anmeldungen und den Erweiterungen, ohne Container und ohne Umweg. macOS bringt die Sandbox ohnehin schon mit, man muss sie nur benutzen.

Bin ich in der Sandbox?

Einer App oder einem Tool sieht man von außen nicht an, ob es in einer Sandbox läuft oder nicht. Mithilfe eines kleinen Status-Menüs zeigt BX an, ob man sich in einer Sandbox befindet, die mit BX gestartet wurde. Das funktioniert auch im Terminal.

In meinem Fall benutze ich überwiegend Visual Studio Code, und zwar in der Sandbox zusammen mit der KI. Manchmal muss ich aber auch an die geschützten Dateien heran. Um hier eine klare Trennung zu haben, habe ich zusätzlich VSCodium installiert, die Community-Variante von Visual Studio Code: Sie läuft außerhalb der Sandbox und ohne KI. Außerdem habe ich die Akzentfarbe jeweils so eingestellt, dass ich leicht erkennen kann, in welchem Editor ich mich befinde.

Und das Netzwerk?

Eine Dateisystem-Sandbox schützt davor, dass Daten gelesen oder verändert werden. Sie schützt nicht davor, dass Daten, die gelesen werden dürfen, irgendwohin geschickt werden.

In BX lässt sich das Netzwerk für eine Sandbox komplett abschalten. Damit ist diese Gefahr gebannt, aber die KI ist dann auch weitgehend nutzlos, denn ohne Netz kann sie weder recherchieren noch Dokumentation lesen oder Pakete installieren.

Ich bevorzuge deshalb den anderen Weg: Dateien, die Claude nichts angehen, bekommt er erst gar nicht zu sehen, und was er nicht lesen kann, kann er auch nicht verschicken. Die KI bleibt so voll nutzbar und die schützenswerten Daten bleiben trotzdem außen vor.