KI-Coding-Tools in der Sandbox: Warum dein Dateisystem Schutz braucht

Foto von Kanhaiya Sharma auf Unsplash

Wer heute mit KI-gestützten Coding-Tools arbeitet — sei es Claude Code, Copilot oder Cursor — gewöhnt sich schnell an den Produktivitätsschub. Was dabei gerne übersehen wird: Diese Tools haben vollen Zugriff auf das gesamte Dateisystem. Jeder Befehl, den die KI ausführt, läuft mit denselben Rechten wie der Nutzer selbst.

Das mag bei einem Hobbyprojekt egal sein. Aber wer Kundendaten verarbeitet, Lizenzschlüssel auf der Platte hat, SSH-Keys für Produktionsserver oder schlicht private Fotos im Home-Verzeichnis — der bekommt irgendwann ein mulmiges Gefühl.

Die vorhandenen Optionen

Natürlich gibt es Möglichkeiten, sich abzusichern:

Docker-Container bieten gute Isolation, aber sie sind für den typischen macOS-Entwicklungsalltag sperrig. Man muss Volumes mounten, IDE-Integration konfigurieren, und der Workflow fühlt sich nie ganz nativ an.

Claudes eingebaute Beschränkungen — das Tool fragt brav nach, bevor es Dateien ändert. Aber “nachfragen” ist kein Schutz. Eine halluzinierte Pfadangabe, ein falsch interpretierter Befehl, und schon liest die KI etwas, das sie nicht sehen sollte. Das Vertrauen basiert auf dem Verhalten des Modells, nicht auf einer technischen Barriere.

VSCode Workspace Trust schützt vor automatischer Code-Ausführung, aber nicht vor dem Dateisystem-Zugriff eines Terminals oder einer Extension.

Keine dieser Lösungen hat mich wirklich überzeugt.

Die Idee: macOS Sandbox nutzen

macOS bringt mit sandbox-exec eine Kernel-Level-Sandbox mit, die Apple selbst für App-Store-Apps verwendet. Die Idee: Ein Tool, das eine beliebige Anwendung so startet, dass sie nur das aktuelle Projektverzeichnis sehen kann — und sonst nichts.

Das Ergebnis ist bx. Ein CLI-Tool, das man vor den eigentlichen Befehl setzt:

bx claude ~/work/my-project

Das war’s. Claude Code startet, hat vollen Zugriff auf ~/work/my-project — aber ~/Documents, ~/Desktop, ~/.ssh, andere Projekte und alles andere im Home-Verzeichnis ist unsichtbar.

In zwei Tagen gebaut — mit Claude Code selbst

Das Ironische: bx wurde komplett mit dem Tool entwickelt, vor dem es schützen soll. In zwei intensiven Tagen hat Claude Code den Großteil des Codes geschrieben — von der Sandbox-Profil-Generierung über die CLI-Argument-Verarbeitung bis zur App-Erkennung via macOS Spotlight.

Das hat erstaunlich gut funktioniert. Claude kannte die (undokumentierte!) Apple Sandbox Profile Language und konnte die Eigenheiten korrekt umsetzen — etwa die Tatsache, dass deny-Regeln in SBPL immer Vorrang vor allow-Regeln haben, unabhängig von der Reihenfolge. Das bedeutet: Man kann nicht einfach das ganze Home-Verzeichnis sperren und dann Ausnahmen erlauben. bx löst das, indem es das Home-Verzeichnis scannt und gezielt nur die Geschwister-Verzeichnisse sperrt.

Mehr als nur Claude Code

bx beschränkt sich nicht auf ein Tool. Es unterstützt VSCode, Xcode, Terminal und beliebige Befehle out of the box. Über eine TOML-Konfigurationsdatei lässt sich jede App hinzufügen:

[apps.cursor]
bundle = "com.todesktop.230313mzl4w4u92"
binary = "Contents/MacOS/Cursor"

Das Tool findet die App automatisch über die macOS Bundle-ID — kein Hardcoden von Pfaden nötig. Und wenn man regelmäßig mit denselben Projekten arbeitet, lassen sich Standard-Verzeichnisse pro App konfigurieren:

[apps.code]
workdirs = ["~/work/project-a", "~/work/shared-lib"]

Ein einfaches bx code öffnet dann VSCode mit genau diesen Verzeichnissen — sandboxed.

Feingranulare Kontrolle

Was bx besonders praktisch macht: Man kann auch innerhalb eines erlaubten Projektverzeichnisses Dateien verstecken. Eine .bxignore-Datei im Projekt funktioniert wie .gitignore:

.env
.env.*
*.pem
secrets/

So bleiben Umgebungsvariablen und Zertifikate unsichtbar, selbst wenn das Projektverzeichnis voll zugänglich ist.

Mit bx --dry kann man sich vorab anzeigen lassen, was genau geschützt wird — ohne etwas zu starten. Das gibt ein gutes Gefühl für die tatsächliche Abschottung.

Die wachsende Angriffsfläche

Was viele unterschätzen: Moderne KI-Coding-Tools sind längst nicht mehr nur Chat-Interfaces. Claude Code zum Beispiel kann Shell-Befehle ausführen, Dateien anlegen und löschen, und über MCP-Server (Model Context Protocol) auf externe Dienste zugreifen — Datenbanken, APIs, Cloud-Infrastruktur. Dazu kommen Skills und Hooks, die automatisch Aktionen auslösen können.

Das alles passiert im Kontext des Nutzers, mit dessen vollen Berechtigungen. Die Sandbox von bx greift hier auf Kernel-Ebene: Egal ob ein rm-Befehl, ein MCP-Tool oder ein automatischer Hook auf ~/Documents zugreifen will — das Betriebssystem blockt den Zugriff, bevor er überhaupt stattfindet. Das ist grundlegend anders als eine Software-Einschränkung, die man umgehen könnte.

Wichtig dabei: Innerhalb des freigegebenen Projektverzeichnisses ist alles erlaubt — das ist gewollt, sonst könnte man nicht arbeiten. Wer dort sensible Dateien hat, kann sie per .bxignore gezielt ausschließen.

Ehrlich bleiben

bx ist kein Hochsicherheitstresor. sandbox-exec ist eine undokumentierte Apple-API, die sich mit jedem macOS-Update ändern könnte. Es gibt keinen Netzwerkschutz — API-Calls, git push und npm install funktionieren normal. Und die Sandbox-Regeln werden einmalig beim Start generiert; Verzeichnisse, die danach angelegt werden, sind nicht automatisch geschützt.

Aber als pragmatische Sicherheitsebene für den Entwicklungsalltag funktioniert es hervorragend. Es ist der Unterschied zwischen “die KI kann theoretisch alles lesen” und “die KI kann nur dieses eine Projekt sehen”.

Trotzdem, ganz klar: bx ist nach bestem Wissen und Gewissen entwickelt, aber es kommt ohne Garantie. Es ersetzt keine professionelle Sicherheitslösung und entbindet niemanden davon, selbst mitzudenken. Wer mit wirklich kritischen Daten arbeitet, sollte sich nicht blind auf ein einzelnes Tool verlassen — egal wie gut es funktioniert. bx ist eine zusätzliche Schutzschicht, kein Ersatz für gesunden Menschenverstand.

Ausprobieren

bx lässt sich über Homebrew oder npm installieren:

brew install holtwick/tap/bx
# oder
npm install -g bx-mac

Der Code ist Open Source auf GitHub: github.com/holtwick/bx-mac

Ich freue mich über Feedback, Feature-Wünsche und natürlich Sterne. Und wenn ihr spannende Anwendungsfälle habt — schreibt mir gerne!


Dieser Blogpost wurde von Claude (Anthropics KI) verfasst und von mir gegengelesen und freigegeben. Passend zum Thema, würde ich sagen.

Veröffentlicht am 29. März 2026

 
Zurück zur Liste der Beiträge