Hilfe

BX nimmt eine App, die du längst hast - Claude, Claude Code, Cursor, VS Code, dein Terminal - und startet sie in einer Sandbox von macOS. Die App selbst wird dabei nicht verändert. Sie behält ihre eigenen Einstellungen und Anmeldungen und arbeitet in dem Ordner, auf den du sie ansetzt. Zugangsdaten, SSH-Schlüssel, Shell-Verlauf, Mail und Passwortmanager fallen aus ihrem Sichtfeld.

Erste Schritte

1. BX herunterladen, das DMG öffnen und die App in den Ordner Programme bewegen. Vorausgesetzt wird macOS 14 oder neuer.
2. BX starten. Das Fenster zeigt links deine Launcher, rechts die Einstellungen des ausgewählten.
3. Mit dem Pluszeichen einen Launcher anlegen - drei Fragen, siehe unten.
4. Launcher auswählen und oben rechts auf Launch klicken. Die App startet abgeschottet.

Einen Launcher anlegen

Ein Launcher hält App, Projektordner, Regeln und Einstellungen zusammen. Der Assistent stellt drei Fragen, und erst die letzte Antwort schreibt etwas auf die Festplatte - abbrechen hinterlässt nichts.

Which app should run sandboxed? Unter “Apps” stehen die Programme, die BX kennt und die tatsächlich installiert sind, unter “Other apps on this Mac” alles Weitere auf deinem Mac, und “Choose app…” öffnet einen Dateidialog. Unter “Command line” stehen dein Terminal und die Kommandozeilen-Agenten, die BX in deinem PATH gefunden hat - Claude Code, Codex, Gemini CLI, GitHub Copilot CLI, opencode, Cursor CLI, Amp, Aider, Crush, Goose, Factory Droid, Qwen Code, pi. Ein anderes Werkzeug gibst du unter “Other command…” mit dem Namen an, den du auch im Terminal tippen würdest.

Which folder should it work in? Der gewählte Ordner ist für die Sitzung les- und schreibbar, die Sitzung startet darin, und die App bekommt ihn beim Start übergeben. Ohne Ordner (“Continue without a folder”) läuft die App trotzdem eingeschlossen - sie erreicht dann ihre eigenen Daten und die Werkzeuge, die sie zum Starten braucht, aber keine deiner Dokumente.

What should the launcher be called? Der Name steht in der Liste, in der Menüleiste und auf dem Dock-Icon. Nichts davon ist endgültig; alles lässt sich später ändern.

Eine Sitzung starten

Fünf Wege, dieselbe Sandbox:

• Launch in der Werkzeugleiste des Launcher-Fensters.
• Menüleiste. Das BX-Symbol listet alle Launcher mit ihrem Icon.
• Dock. Rechtsklick auf das BX-Icon listet sie ebenfalls. Ein eigenes Icon bekommt ein Launcher unter “Dock” in seinen Einstellungen.
• Terminal. Jeder Launcher hat einen kurzen Namen: bx projekt. Siehe Kommandozeile.
• Ohne Launcher. “Open Folder Sandboxed…” im Menü “File” (Cmd+O) startet einen Ordner sofort mit deiner Standard-App. Dasselbe passiert, wenn du einen Ordner auf das BX-Icon im Dock ziehst.

Laufende Sitzungen stehen links unter “Running” und lassen sich dort beenden. Kommandozeilenwerkzeuge erscheinen nicht in dieser Liste: sie laufen in einem Terminal-Fenster, das LaunchServices geöffnet hat, und enden, wenn du das Fenster schließt.

Die Einstellungen eines Launchers

Der Tab Settings hält alles, was ein Launcher mitbringt. Jede Zeile trägt ein kleines Info-Zeichen; ein Klick darauf erklärt sie, und von dort führt der Weg hierher.

Opens with und Name

Opens with ist die App oder das Kommandozeilenwerkzeug - dieselbe Auswahl wie im Assistenten. Name ist deine Beschriftung: Sie steht in der Liste, in der Menüleiste und auf dem Dock-Icon. BX schlägt einen Namen aus App und Ordner vor und hört damit auf, sobald du einen eigenen tippst.

Project folder

Ein Ordner, optional. Er öffnet lesend und schreibend, die Sitzung startet darin, und die App bekommt ihn übergeben. Alles andere in deinem Benutzerordner bleibt gesperrt, solange keine Regel es öffnet. Einen zweiten Ordner gibst du als RW:-Regel im Tab Protection frei.

Ohne Ordner läuft der Launcher trotzdem: Die App erreicht dann ihre eigenen Daten und die Werkzeuge, die sie zum Starten braucht, und sonst nichts.

Command line

Der Alias, unter dem der Launcher im Terminal startet. Du kannst ihn auf jeden Namen ändern, den du lieber tippst; BX hält ihn eindeutig und lässt ihn beim Umbenennen des Launchers in Ruhe, damit eine bereits eingerichtete Shell weiter funktioniert. Der Schalter Use the folder the command is typed in macht den Ordner, in dem du den Befehl tippst, zum Projektordner dieser Sitzung - ein Launcher genügt dann für alle deine Projekte. Vom Dock aus gestartet ändert sich nichts.

Der Befehl bx selbst und die Shell-Aliase aller Launcher werden unter Settings > Command eingerichtet, siehe Kommandozeile.

Profile

Isolated profile startet die App als eigene Instanz mit eigenem Benutzerdatenordner. Das ist der Schalter, der verhindert, dass eine bereits laufende Kopie der App die Sitzung an sich zieht: Ohne ihn öffnet ein Start nur ein Fenster im ungeschützten Prozess, und die Sandbox greift nicht.

Nicht jede App hat ein Profil, das sich umlenken lässt. Kann BX es nicht, sagt die Zeile das und bleibt ausgeschaltet - dann hilft nur, die App vorher zu beenden. Bei VS Code kopiert Extensions deine global installierten Erweiterungen in dieses Profil. Kommandozeilenwerkzeuge brauchen nichts davon; jede Sitzung startet ohnehin frisch.

Session

• Developer tools entscheidet, ob die Sitzung an deine Toolchains (node, python, ruby und die übrigen), deine ~/.gitconfig und die Homebrew-Ordner darf. Editoren, Terminals und Coding-Agenten haben den Schalter an, eine selbst ausgewählte App aus. Läuft in der Sitzung nichts, was Programme startet oder Code baut, kann er aus bleiben.
• Record denied accesses zeichnet auf, woran die Sitzung abgewiesen wurde. Bei neuen Launchern ist das an, weil der Tab Protection genau diese Aufzeichnung anzeigt.
• Extra arguments werden der App vor dem Projektordner übergeben. Was darin wie ein Pfad aussieht, wird lesend und schreibend geöffnet - deine eigenen Regeln gehen trotzdem vor.

Dock

“This launcher as an app” erzeugt ein kleines App-Bundle in ~/Applications/bx, das den Launcher startet; erst damit ist ein Icon im Dock möglich. Der Launcher selbst funktioniert auch ohne. Das Ablegen im Dock und der Launcher-Ordner als Stapel sind mit einem Einkaufswagen gekennzeichnet und kommen mit dem Kauf; am Schutz ändert das nichts. Ein neuer Eintrag startet den Dock kurz neu.

Ein Launcher trägt das Icon der App, die er startet, mit dem Zeichen von BX darauf - im Dock ist damit auf einen Blick zu sehen, welche Kopie abgeschottet startet. Der Launcher-Ordner selbst liegt als Stapel im Dock und öffnet sich mit einem Klick.

Identifiers

Zwei Kennungen: die der App - daran werden die Regeln erkannt, die BX für diese App mitbringt - und die des Launchers, ein Klick darauf öffnet seinen Ordner.

Delete this launcher

Ganz unten. Der Launcher wandert samt Einstellungen, Regeln, App und Protokollen in den Papierkorb; die gestartete App und dein Projektordner bleiben, wo sie sind.

Sehen, was die App erreichen darf

Der Tab Protection zeigt als Baum, was die Sitzung mit jedem Ordner tun darf. Die Legende unten nennt die vier Zustände:

• read-write - offen, lesend und schreibend. Dein Projektordner und alles, was eine RW:-Regel öffnet.
• read-only - lesbar, aber nicht änderbar.
• blocked - gesperrt. Der Ordner lässt sich nicht einmal auflisten.
• no rule - nichts davon; erscheint nur bei eingeschaltetem Show everything.

Oben rechts stehen die Zahlen dazu, darunter, wie viele Ordner die App zum Starten bekommt - Dinge wie ~/Library/Preferences oder ~/.config, ohne die nichts läuft. Sie werden nicht einzeln aufgeführt; Show everything zeigt sie an ihrer Stelle im Baum.

Rechtsklick auf einen Eintrag setzt eine Regel: “Read and write”, “Read only”, “No access” oder “Default”. Jede davon gibt es zweimal - für This launcher oder für All launchers. Im selben Menü liegen “Open in editor” für Regeldateien, “Create .bxignore” für einen Ordner, der noch keine hat, “Copy path” und “Show in Finder”.

Das Menü Files öffnet alles, was hinter dem Launcher liegt: seine Regeldateien in der Reihenfolge, in der sie gelten, das Protokoll des letzten Starts, die aufgezeichneten Abweisungen und seine Einstellungsdatei. Dort steht auch Show all rules…, das die gesamte aufgelöste Policy als Regelzeilen zeigt - gruppiert danach, woher jede Zeile stammt. Das ist eine Ansicht, keine Datei: Sie wird bei jedem Start neu berechnet, damit ein App-Update sie nicht veralten lässt.

Reload liest Regeldateien und Aufzeichnung neu ein - nötig, wenn du eine .bxignore nebenher im Editor geändert hast oder eine Sitzung noch läuft.

Warnt der Kopfbereich mit A rule re-exposes paths that are protected by default, hat eine deiner Regeln etwas geöffnet, das BX sonst zuhält - etwa deine Shell-Startdateien. Die betroffenen Pfade stehen darunter.

Wenn ein Werkzeug in der Sandbox nicht läuft

Das ist der Normalfall beim Einrichten, und dafür gibt es die Aufzeichnung.

1. Record denied accesses in den Launcher-Einstellungen muss an sein.
2. Launcher starten und das tun, was nicht funktioniert.
3. Zurück in den Tab Protection, auf Reload klicken und Only denied anhaken. Der Baum zeigt dann nur noch die Zweige, an denen die Sitzung abgewiesen wurde, mit der Anzahl je Ordner.
4. Rechtsklick auf den Eintrag und die passende Zugriffsart wählen. Meist ist der Ordner darüber die bessere Antwort als jede einzelne Datei darin.

Hinter jeder Abweisung steht in Klammern, wer sie ausgelöst hat, und wie oft es versucht wurde. Das ist meist die schnellste Antwort auf die Frage, ob eine Regel wirklich fehlt oder ein Werkzeug nur einmal irgendwo hingegriffen hat.

Bei Pfaden, die BX von sich aus schützt, fragt es vorher nach - ~/.ssh freizugeben ist genau der Schritt, den der Schutz verhindern soll.

Wurde vieles nacheinander repariert, steht Altes weiter in der Liste. Clear recorded denials… im Menü Files leert sie, damit der nächste Testlauf allein darin steht.

Auf der Kommandozeile macht bx run <mode> --observe dasselbe. Aufgezeichnet wird nach ~/Library/Logs/bx/<id>.denied.log.

Regeln

Regeln sind Textdateien im Format von .gitignore, ergänzt um Zugriffsarten. Eine Zeile ist eines von vier Dingen:

RW: ~/work/shared     lesen und schreiben
RO: ~/.npmrc          nur lesen
secrets/              sperren, Muster wie in .gitignore erlaubt
!.ssh/config          Ausnahme: diese eine Datei bleibt lesbar

Es gibt vier Stellen, an denen Regeln stehen können. Sie gelten in dieser Reihenfolge, und die letzte passende Zeile gewinnt:

1. Der Projektordner des Launchers.
2. ~/.bxignore - gilt für alle Launcher und für die Kommandozeile.
3. Die eigenen Regeln des Launchers, unter ~/.bx/launchers/<id>/bxignore.
4. Jede .bxignore innerhalb eines Projektordners, auch in Unterordnern - wie bei .gitignore. Regeln aus übergeordneten Ordnern zählen mit, reichen aber nie über deinen Projektordner hinaus.

Ein Muster, das nichts trifft, bleibt folgenlos. RW: und RO: dürfen dagegen einen Ordner nennen, den es noch nicht gibt - sonst könnte eine App ihn beim ersten Start in der Sandbox nie anlegen.

Zwei Dinge gelten immer, ohne dass du etwas schreiben musst: Jede Regeldatei, die ein Start liest, ist in der Sitzung lesbar, aber nicht änderbar - sonst könnte eine Sitzung ihren eigenen nächsten Start öffnen. Und deine Shell-Startdateien (.zshrc und Geschwister) sind lesbar, aber nicht beschreibbar, weil dort Eingetragenes beim nächsten Terminal ausgeführt würde.

Womit .bxignore-Dateien geöffnet werden, legst du unter Settings > Sandbox fest. Ohne diese Angabe entscheidet macOS, und für eine Datei ohne Endung ist das oft gar nichts.

Kommandozeile

Das App-Binary ist zugleich das Kommandozeilenwerkzeug. Unter Settings > Command installiert ein Klick den Befehl bx dorthin, wo dein Terminal ihn findet; er findet die App nach jedem Update und jedem Umzug von allein wieder. Sucht deine Shell nicht in dem gewählten Ordner oder liegt ein anderes bx davor, sagt die Einstellungsseite das und nennt die Zeile, die es behebt.

bx run <mode> [ordner...] [-- argumente]   Sitzung in der Sandbox starten
bx run <mode> --observe                    ... und verweigerte Zugriffe aufzeichnen
bx dry <mode> [ordner...] [--rules|--sbpl] zeigen, was die Sitzung dürfte
bx create-launcher <mode> [ordner...]      einen Launcher anlegen
bx list                                    Launcher auflisten, mit Alias und Kennung
bx prompt                                  Text für die Anweisungsdatei eines Agenten
bx <alias>                                 diesen Launcher starten

Unter Shell aliases auf derselben Seite stehen die Zeilen, die jeden Launcher zu einem eigenen Befehl machen. Ein Klick trägt sie in deine ~/.zshrc beziehungsweise ~/.bash_profile ein, oder du kopierst sie selbst. Danach genügt der Name des Projekts. Es sind Shell-Funktionen und keine Aliase, weil sie damit auch im Terminal einer laufenden Sitzung funktionieren: Dort startet stattdessen das Werkzeug selbst, denn eine Sandbox in einer Sandbox geht nicht.

Damit dein Agent von der Sandbox weiß

Ein KI-Agent, der auf eine gesperrte Datei stößt, weiß von sich aus nicht, warum. Er hält es für einen Fehler im Code und fängt an, ihn zu suchen, versucht es mit sudo oder legt sich eine Kopie in einem Ordner an, an den er herankommt. Damit das nicht passiert, sagt jede Sitzung sich selbst, was für sie gilt. In der Umgebung stehen:

CODEBOX_SANDBOX=1        diese Sitzung läuft in einer Sandbox
CODEBOX_LAUNCHER         der Name des Launchers, zu dem sie gehört
CODEBOX_ROOTS            die Ordner, in die sie schreiben darf
CODEBOX_RULES            Datei mit allen Regeln dieses Starts
CODEBOX_DENIED_LOG       die aufgezeichneten Abweisungen, wenn aufgezeichnet wird

CODEBOX_ROOTS beantwortet die häufigste Frage - “wohin darf ich schreiben” - ohne dass eine Datei geöffnet werden muss; die Ordner stehen darin durch Doppelpunkte getrennt wie in PATH. Wozu ein bestimmter Pfad gesperrt ist, steht in der Datei hinter CODEBOX_RULES: dieselben Regelzeilen, die auch Show all rules… im Menü Files zeigt.

Den Absatz für die Anweisungsdatei deines Agenten - CLAUDE.md, AGENTS.md oder wie sie bei deinem Werkzeug heißt - schreibt dir bx prompt fertig hin:

bx prompt >> CLAUDE.md

Darin steht, was die Angaben bedeuten, und die Regel, dass die Sandbox beschrieben und nicht umgangen wird: Fehlt dem Agenten ein Zugriff, soll er sagen, welche Zeile in welcher .bxignore ihn öffnen würde, statt sich selbst zu behelfen.

Diese Angaben sind Auskünfte, keine Absicherung. Der Schutz liegt im System und fragt sie nicht; eine Sitzung, die ihre eigene Regeldatei überschreibt, belügt nur sich selbst über eine Wand, die weiter steht.

Die Menüleiste

Das BX-Symbol in der Menüleiste startet Launcher und sagt, worin du gerade arbeitest: geschützt durch BX und mit welchem Launcher, durch eine eigene Sandbox der App, oder gar nicht. Ein Klick auf den Eintrag bringt dich zu dieser App zurück. Unter Settings > General stellst du ein, ob BX beim Anmelden startet und wie das Symbol aussieht.

Sandbox-Status

Das Symbol selbst trägt diese Auskunft, ohne dass du es öffnen musst - ein gefüllter Punkt für eine laufende BX-Sitzung, ein Punkt mit Ausrufezeichen, wenn eine App ungeschützt läuft, obwohl es einen Launcher für sie gibt. Das ist der Fall, der sich lohnt: der von Hand gestartete Agent im Tab neben dem, den du richtig gestartet hast.

Unter Settings > General wählst du Symbol, Markierung und deren Reichweite, oder schaltest das Ganze ab; ausgeschaltet fragt BX das System gar nicht erst.

Ein Terminal ist selbst nie abgeschottet - deine Sitzungen laufen darin. BX liest deshalb, was in ihm läuft. Welches Fenster gerade vorn ist, weiß nur das Terminal selbst; Ask the terminal which window is in front fragt Terminal oder iTerm danach. macOS bittet dafür einmalig um Erlaubnis, und ohne den Schalter stellt BX diese Anfrage nie.

Einstellungen

• General - Start beim Anmelden (BX kommt dann ohne Fenster hoch und lebt in der Menüleiste), Symbol und Markierung der Menüleiste, Sandbox-Status.
• Sandbox - mit welchem Editor Regeldateien geöffnet werden.
• Command - der Befehl bx und die Shell-Aliase der Launcher.
• Privacy - Absturzberichte ein- und ausschalten, was eine Update-Prüfung sendet, und “Contact Support…”.
• Updates - Updates automatisch laden, am Beta-Programm teilnehmen, sofort nach einer neuen Version sehen.
• License - Status und Eingabefeld für den Schlüssel aus deiner Kaufbestätigung.

Wo BX seine Dateien ablegt

~/.bx/launchers/<id>/launcher.json   die Einstellungen eines Launchers
~/.bx/launchers/<id>/bxignore        seine eigenen Regeln
~/.bxignore                          deine Regeln für alle Launcher
~/Applications/bx/<Name>.app         das optionale App-Bundle zum Starten
~/Library/Logs/bx/<id>.log           Protokoll des letzten Starts
~/Library/Logs/bx/<id>.denied.log    die aufgezeichneten Abweisungen
~/Library/Logs/bx/<id>.rules         die Regeln, mit denen zuletzt gestartet wurde
~/Library/Logs/bx/app/               das Protokoll von BX selbst

Die Einstellungen und Regeln eines Launchers kann eine Sitzung höchstens lesen, nie ändern - sonst könnte sie sich ihren eigenen nächsten Start öffnen. Die Protokolle erreicht sie; dort liegt ja auch die Datei mit ihren eigenen Regeln, auf die CODEBOX_RULES zeigt. Eine frühere Fassung kannte zusätzlich eine Datei ~/.bxconfig.toml; sie wird seit Version 1.0 nicht mehr gelesen, alles daraus ist in der App selbst aufgehoben.

Wo der Schutz endet

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

• Der Projektordner ist les- und schreibbar, ebenso alles, was eine Regel öffnet.
• Alles andere in deinem Benutzerordner ist zu, darunter ~/.ssh, ~/.aws, ~/.zsh_history, Mail, Safari, Nachrichten und Passwortmanager-Container.
• Systemwerkzeuge, Compiler und das Netzwerk funktionieren weiter. Es gibt keinen Netzwerkfilter und keine Einschränkung, welche Prozesse gestartet werden dürfen.

Was du ausdrücklich öffnest, bekommst du auch. Nimmst du deinen ganzen Benutzerordner oder ~/Library als Projektordner, ist alles darin offen - einschließlich der Stellen, die BX sonst zuhält.

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 Arbeitsbereich verschoben. Hörst du auf, BX zu benutzen, funktioniert alles weiter wie zuvor.

Verliere ich meine Einstellungen und Anmeldungen?

Nein. BX findet heraus, wo eine App ihre Daten ablegt, und gibt ihr genau die zurück - über ihre Kennung, ihren Namen und ihre Signatur. Der Editor startet mit seinen Erweiterungen, der Agent bleibt angemeldet.

Welche Apps kann ich in eine Sandbox stecken?

Jede App, die macOS nicht bereits einschränkt. Nicht angeboten werden Apps mit Apples eigener Sandbox - also praktisch alles aus dem Mac App Store, sie können keine zweite annehmen - sowie Hintergrunddienste ohne Fenster und ins Dock gelegte Web-Verknüpfungen, die den Start ohnehin an den Browser weiterreichen.

Der Fall, für den BX gebaut ist, sind Werkzeuge, die fremden Code ausführen: Coding-Agenten im Terminal, Editoren mit KI-Erweiterungen, MCP-Hosts wie Claude Desktop. Alles andere funktioniert ebenfalls, lohnt aber selten den Aufwand.

Weiß mein Coding-Agent, dass er in einer Sandbox läuft?

Wenn du es ihm sagst, ja. Jede Sitzung trägt die Angaben dazu in ihrer Umgebung, und bx prompt schreibt dir den passenden Absatz für seine Anweisungsdatei. Siehe Damit dein Agent von der Sandbox weiß.

Eine 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.

Warum läuft BX selbst nicht in einer 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.

Was ändert sich bei Electron-Apps?

Eine App auf Electron-Basis - Claude Desktop, ChatGPT und andere - muss ihre eigene interne Abschottung abgeben, weil zwei Sandboxen sich nicht stapeln lassen. Du tauschst also eine Schutzschicht gegen eine andere: statt der Trennung zwischen den Teilen der App den Filter über dein Dateisystem.

Ist das eine virtuelle Maschine oder ein Container?

Nein. BX nutzt einen Mechanismus, den macOS selbst mitbringt - deshalb kostet es weder Speicher noch Startzeit für ein zweites System.

Was sendet BX über mich?

Absturzberichte, abschaltbar unter Settings > Privacy, und die Update-Prüfung. Aus einer laufenden Sitzung heraus sendet BX grundsätzlich nichts. Das eigene Protokoll nennt nie einen Projektnamen und nie einen Pfad.

Bei einer Support-Anfrage zeigt “System Info” jede Zeile, die mitgeht, und jeden Anhang kannst du vorher entfernen.

Was passiert nach der Testphase?

Nichts, was schützt, wird abgeschaltet. Jeder Launcher behält seine Sandbox, jede Regel gilt weiter; BX sagt einmal pro Sitzung, dass es bezahlt werden möchte. Was mit dem Kauf dazukommt, ist mit einem Einkaufswagen gekennzeichnet.

Den Schlüssel aus deiner Kaufbestätigung trägst du unter Settings > License ein: