Hilfe

BX nimmt eine App, die du längst hast – Claude Code, Cursor, dein Terminal, VS Code, was auch immer – und startet sie innerhalb einer Seatbelt-Sandbox. Die App selbst wird dabei nicht verändert. Sie behält den Projektordner, auf den du sie ansetzt; Zugangsdaten, Shell-History, Mail und Passwort-Manager-Container fallen aus ihrem Sichtfeld.

Erste Schritte

  1. BX herunterladen, das DMG öffnen und die App in den Ordner Programme bewegen.
  2. BX starten und einen Launcher anlegen: App auswählen, Projektordner festlegen, auf den zugegriffen werden darf, und den Schutzmodus wählen.
  3. Die Policy-Vorschau prüfen. Sie listet jeden Ordner auf, den die Sitzung lesen und schreiben kann.
  4. Sichern. Der Launcher liegt in ~/Applications/bx/ und erscheint im Launchpad – starte ihn wie jede andere App.

Launcher lassen sich direkt aus dem Editor ins Dock legen. Danach ist die abgesicherte Sitzung einen Doppelklick entfernt – genau wie die App, von der du ausgegangen bist.

Was eine Sitzung darf und was nicht

BX ist ein Lesefilter für das Dateisystem. Innerhalb einer Sitzung gilt:

  • Die angegebenen Projektordner sind les- und schreibbar.
  • Alles andere im Benutzerordner ist abgeriegelt, darunter ~/.ssh, ~/.aws, ~/.zsh_history, Mail, Safari, Nachrichten und Passwort-Manager-Container.
  • Systemwerkzeuge, Compiler und das Netzwerk funktionieren weiter. Es gibt keinen Netzwerkfilter und keine Einschränkung, welche Prozesse gestartet werden dürfen.

Reichweite

BX schützt vor Neugier und Versehen, nicht vor einem Angreifer. Ausbrüche aus Seatbelt sind dokumentiert, und was ein Prozess lesen kann, kann er auch senden. Nutze BX nicht als Käfig für Software, die du für bösartig hältst.

Verweigerte Zugriffe aufzeichnen

Aktiviere in den Launcher-Einstellungen Verweigerte Zugriffe aufzeichnen oder rufe auf der Kommandozeile bx run <mode> --observe auf. Jeder blockierte Pfad wird nach ~/Library/Logs/bx/<launcher>.denied.log geschrieben.

Verweigerte Zugriffe anzeigen listet alles auf, was ein Launcher über alle Sitzungen hinweg nicht bekommen hat. Von dort lässt sich ein Pfad für Lesen oder Lesen und Schreiben freigeben; das schreibt eine RO:- bzw. RW:-Zeile in ~/.bxignore. Pfade auf den eingebauten Schutzlisten fragen vorher nach – ~/.ssh freizugeben ist genau der Schritt, den der Schutz verhindern soll.

Das ist der schnellste Weg herauszufinden, warum ein Werkzeug nicht läuft: Die Liste sagt, was gefehlt hat, und der Knopf gibt es frei.

Konfigurationsdateien

BX liest dieselben Dateien wie das Kommandozeilenwerkzeug bx:

  • ~/.bxconfig.toml – globale Konfiguration.
  • .bxignore – pro Projekt, in gitignore-Syntax, ergänzt um RO:- und RW:-Zeilen für ausdrückliche Freigaben.

Die Referenz für beide Formate ist das Repository bx-mac.

Kommandozeile

Das App-Binary ist zugleich das Kommandozeilenwerkzeug. Es liegt unter BX.app/Contents/MacOS/bx.

bx run <mode> [workdir...] [-- app args]   Sitzung in der Sandbox starten
bx run <mode> --observe                    ... und verweigerte Zugriffe melden
bx dry <mode> [workdir...] [--sbpl]        resultierende Policy anzeigen
bx create-launcher <mode> <workdir...>     einen .app-Launcher erzeugen
bx list                                    erzeugte Launcher auflisten

Häufige Fragen

Muss ich meine Apps ändern oder neu installieren?

Nein. BX startet die App, die ohnehin installiert ist, von dort wo sie installiert ist, mit dem Projektordner, in dem du ohnehin arbeitest. Nichts wird kopiert, umgeschrieben oder in einen speziellen Workspace verschoben. Hörst du auf, BX zu benutzen, funktioniert alles weiter wie zuvor.

Welche Apps kann ich in eine Sandbox stecken?

Jede App, die nicht bereits von macOS eingeschränkt wird. Die gängigen – Terminals, Editoren, IDEs – werden automatisch erkannt, inklusive der Electron-Eigenheiten, die sie sonst am Start hindern würden.

Der Fall, für den BX gebaut ist, sind KI-Apps:

  • Claude und vergleichbare MCP-Hosts. Der Wert steckt dort in den Servern, nicht in der App – npx irgendein-mcp-server ist fremder Code, der als Kindprozess mit deinen vollen Rechten läuft. Beende die App, bevor du den Launcher startest, siehe unten.
  • Terminal-Harnesses – Claude Code, Codex, aider, opencode, goose.
  • Editoren mit KI-Erweiterungen – VS Code, Cursor, Windsurf, Zed, JetBrains.

Alles andere funktioniert ebenfalls, lohnt aber selten den Aufwand. Es profitieren die Apps, die Code ausführen, den du nicht selbst geschrieben hast.

Warum läuft BX selbst nicht in der Sandbox?

Ein bereits eingesperrter Prozess kann kein Seatbelt-Profil anwenden – sandbox_apply scheitert mit EPERM. Aus demselben Grund gibt es BX nicht im Mac App Store.

Warum müssen Launcher lokal erzeugt werden?

Ein Bundle, das in einem DMG ausgeliefert wird, trägt com.apple.quarantine und scheitert unsigniert an Gatekeeper. Ein lokal erzeugter Launcher trägt dieses Attribut nicht, deshalb ist keine Signatur nötig.

Eine GUI-App öffnet ein Fenster, läuft aber nicht in der Sandbox. Warum?

Läuft die App bereits ungeschützt, öffnet ein zweiter Start nur ein Fenster im bestehenden Prozess. Beende die App zuerst und starte dann den Launcher.

Funktioniert BX mit Apps, die bereits sandboxed sind?

Apps mit App-Sandbox-Entitlement werden bereits von macOS eingeschränkt. Für sie bringt BX nichts zusätzlich.

Wo liegen die Logs?

Sitzungs- und Zugriffs-Logs liegen in ~/Library/Logs/bx/, die Launcher in ~/Applications/bx/.