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. BX läuft auf macOS 26 und 27.
2. BX starten. Das Fenster zeigt links deine Launcher, rechts die Einstellungen des ausgewählten.
3. Mit dem Pluszeichen oder mit “Neuer Launcher…” im Menü “Ablage” (Cmd+N) einen Launcher anlegen - drei Schritte, siehe unten.
4. Launcher auswählen und oben rechts auf Starten klicken. Die App startet abgeschottet.

Einen Launcher anlegen

Ein Launcher hält App, Projektordner, Regeln und Einstellungen zusammen. Der Assistent führt durch drei Schritte, und erst der letzte schreibt etwas auf die Festplatte - abbrechen hinterlässt nichts.

App oder Befehl auswählen Unter “Apps” stehen die Programme, die BX kennt und die tatsächlich installiert sind, unter “Weitere Apps auf diesem Mac” alles Weitere auf deinem Mac, und “App auswählen…” öffnet einen Dateidialog. Unter “Kommandozeile” 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 “Anderer Befehl…” mit dem Namen an, den du auch im Terminal tippen würdest. Was ein bestimmtes Werkzeug zum Arbeiten braucht, richtet BX von sich aus ein.

Arbeitsordner auswählen Der Schritt zeigt deinen Benutzerordner als Baum, mit einem Häkchen vor jedem Ordner. Angehakte Ordner sind für die Sitzung les- und schreibbar; im ersten angehakten startet die Sitzung, und die App bekommt ihn beim Start übergeben. Ohne Häkchen (“Ohne Ordner weiter”) läuft die App trotzdem eingeschlossen - sie erreicht dann ihre eigenen Daten und die Werkzeuge, die sie zum Starten braucht, aber keine deiner Dokumente. Versteckte Ordner, Nur-Lesen und einzelne Dateien regelst du später im Tab “Schutz”.

Wie soll der Launcher heißen? 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:

• Starten 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. “Ordner abgeschottet öffnen…” im Menü “Ablage” (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 “Läuft” und lassen sich dort beenden, ebenso im Menüleisten-Symbol und im Dock-Menü. 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 Einstellungen zeigt oben, was immer wieder gebraucht wird - den Namen und das Dock. Alles Übrige wird einmal eingerichtet und liegt zusammengeklappt unter Erweitert. Jede Zeile trägt ein kleines Info-Zeichen; ein Klick darauf erklärt sie, und von dort führt der Weg hierher.

Name

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.

Dock

Diesen Launcher als 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 Alle Launcher 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.

Erweitert

Alles, was ein Launcher einmal mitbekommt und danach höchstens noch gelesen wird: welche App er startet, welchen Ordner er öffnet, wie er im Terminal heißt und wie weit die Sitzung reicht. Der Assistent hat die ersten beiden Angaben schon abgefragt, deshalb ist der Bereich zugeklappt. Klappst du ihn auf, bleibt er offen - für alle Launcher zugleich.

Öffnet mit

Die App oder das Kommandozeilenwerkzeug, das dieser Launcher startet - dieselbe Auswahl wie im Assistenten.

Projektordner

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

Alias

Der Name, 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 Den Ordner nehmen, in dem der Befehl getippt wird 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 Einstellungen > Befehl eingerichtet, siehe Kommandozeile.

Terminal

Startet der Launcher ein Kommandozeilen-Werkzeug, öffnet sich dafür ein Terminalfenster - aus dem Dock, aus der Menüleiste oder aus BX heraus. Welches Programm dieses Fenster stellt, wählst du hier: Terminal, iTerm2 und Ghostty stehen namentlich zur Auswahl, jede andere App über Andere App…. Voreingestellt folgt der Launcher der Einstellung unter Einstellungen > Befehl, die für alle gilt; hier stellst du einen einzelnen Launcher anders ein - etwa einen Coding-Agenten, der ein Fenster für sich haben soll.

Die App muss ein Shell-Skript ausführen, wenn es mit ihr geöffnet wird. Terminal, iTerm2 und Ghostty tun das; kitty, WezTerm und Alacritty erwarten stattdessen eine Angabe auf der Kommandozeile und lassen sich so nicht ansprechen. Wählst du eine App, die den Dateityp nicht annimmt, sagt BX das unter der Zeile.

Das Terminalfenster selbst läuft nie in einer Sandbox - die Sitzung darin schon, und in jedem Terminal gleich. Tippst du den Befehl eines Launchers selbst ein, bleibt die Sitzung in dem Fenster, in dem du sie gestartet hast; diese Einstellung gilt dann nicht.

Was die Sitzung mitbekommt

• Entwicklerwerkzeuge 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.
• Zusätzliche Argumente 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.
• Abgewiesene Zugriffe aufzeichnen zeichnet auf, woran die Sitzung abgewiesen wurde. Bei neuen Launchern ist das an, weil der Tab Schutz genau diese Aufzeichnung anzeigt.

Zwei Einstellungen regeln nicht, was die Sitzung sehen darf, sondern wie weit sie hinausreicht:

• Dateien und Links in anderen Apps öffnen erlaubt der Sitzung, eine Datei oder einen Link an eine andere App weiterzureichen - open im Terminal, “Im Finder zeigen”, ein Link im Browser. Was so geöffnet wird, startet macOS selbst: Es gehört damit nicht mehr zur Sitzung, läuft ohne deren Beschränkungen und sieht deinen ganzen Benutzerordner. Für einen Editor ist das erwünscht, für einen Coding-Agenten selten. Voreingestellt ist der Schalter an.
• Netzwerk entscheidet, wie weit die Sitzung ins Netz reicht:
  • Voller Zugriff - wie jedes andere Programm auch. Voreinstellung.
  • Nur dieser Mac - die Sitzung erreicht 127.0.0.1 und sonst nichts. Ein Entwicklungsserver, eine lokale Datenbank oder ein lokal laufender MCP-Server arbeiten weiter, nach draußen geht nichts.
  • Kein Netzwerk - keine Verbindungen und keine Namensauflösung. Was innerhalb des Rechners läuft, bleibt erreichbar: Der SSH-Agent antwortet, tmux startet, ein Datenbank-Socket im Dateisystem ist da.

Einzelne Adressen oder Webseiten lassen sich nicht freigeben. Die Sandbox von macOS kann einen Port benennen, aber keine Gegenstelle - “nur diese eine API” ist damit nicht zu machen, dafür braucht es einen Proxy oder ein Werkzeug wie Little Snitch.

Kennungen

Ganz unten in Erweitert, zwei Zeilen zum Lesen: App-Kennung - daran werden die Regeln erkannt, die BX für diese App mitbringt - und Launcher-Kennung, ein Klick darauf öffnet den Ordner des Launchers.

Diesen Launcher löschen

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 Schutz zeigt als Baum, was die Sitzung mit jedem Ordner tun darf. Die Legende unten nennt die Zustände:

• lesen und schreiben - offen, lesend und schreibend. Dein Projektordner und alles, was eine RW:-Regel öffnet.
• nur lesen - lesbar, aber nicht änderbar.
• gesperrt - zu. Der Ordner lässt sich nicht einmal auflisten.
• keine Regel - nichts davon; kommt erst dazu, wenn Alles anzeigen eingeschaltet ist.
• in einer Sitzung abgewiesen - kommt dazu, sobald eine Aufzeichnung vorliegt.

Ordner, die die App nur zum Starten bekommt - ~/Library/Preferences oder ~/.config, ohne die nichts läuft -, führt der Baum nicht einzeln auf. Alles anzeigen zeigt sie an ihrer Stelle.

Im Baum bewegen geht wie im Finder: ein Klick auf das Dreieck öffnet einen Ordner, ein Doppelklick auf die Zeile ebenso. Mit gedrückter Alt-Taste geht der ganze Zweig darunter auf oder zu. Dasselbe ohne Maus über die Pfeiltasten: rechts öffnet und steigt hinein, links schließt und geht wieder nach oben, mit Alt jeweils für den ganzen Zweig. Tippst du die ersten Buchstaben eines Namens, springt die Auswahl dorthin - auch bei Punktnamen wie .ssh. Welche Ordner du geöffnet und welche du zugeklappt hast, merkt sich BX - für alle Launcher und über den nächsten Start hinaus. Zum Aufräumen liegen im Rechtsklick-Menü Alle zuklappen und Geöffnete Ordner vergessen.

Rechtsklick auf einen Eintrag setzt eine Regel: “Lesen und schreiben”, “Nur lesen”, “Kein Zugriff” oder “Standard”. Jede davon gibt es zweimal - für Dieser Launcher oder für Alle Launcher. Im selben Menü liegen “Im Editor öffnen” für Regeldateien, “.bxignore anlegen” für einen Ordner, der noch keine hat, “Pfad kopieren” und “Im Finder zeigen”.

Das Menü Dateien ö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 Alle Regeln zeigen…, 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.

Neu laden liest Regeldateien und Aufzeichnung neu ein. Meist brauchst du ihn nicht: Die Regeldateien, die zu diesem Launcher gehören, holt sich BX von selbst, sobald du in den Tab wechselst oder zur App zurückkommst. Der Knopf bleibt für den Rest - die Aufzeichnung einer laufenden Sitzung und eine Regeldatei, die es beim letzten Blick noch gar nicht gab.

Warnt der Kopfbereich mit Eine Regel gibt Pfade wieder frei, die standardmäßig geschützt sind, 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. Abgewiesene Zugriffe aufzeichnen in den Launcher-Einstellungen muss an sein.
2. Launcher starten und das tun, was nicht funktioniert.
3. Zurück in den Tab Schutz, auf Neu laden klicken und Nur abgewiesene 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.

Was gar kein Pfad ist, sammelt BX darunter unter Abgewiesen, was keine Regel öffnen kann - ein angefragtes Systemrecht etwa, oder eine Abfrage des freien Speicherplatzes. Dafür gibt es nichts freizugeben; der Abschnitt sagt zu jedem Eintrag, warum er da steht und ob er stört.

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. Aufgezeichnete Abweisungen löschen… im Menü Dateien 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.

Was dir dabei begegnen wird

Ein paar Dinge sehen nach einem Fehler in BX aus und sind keiner. Sie kommen oft genug vor, dass sie hier stehen.

Die App kann sich nicht mehr selbst aktualisieren. Das Update wird noch geladen, beim Installieren bricht es ab - bei ChatGPT etwa mit der Meldung “An error occurred while launching the installer”. Installieren heißt nämlich, das Programm im Ordner Programme auszutauschen, und dafür fordert die App zusätzlich ein Systemrecht an. Beides ist in der Sandbox zu, und zwar mit Absicht: Wer in Programme schreiben darf, kann jedes Programm auf deinem Mac austauschen, und das nächste startet dann ohne Sandbox und mit deinem ganzen Benutzerordner. Der Weg drumherum dauert eine halbe Minute - Launcher beenden, die App einmal normal über Finder oder Dock starten, dort aktualisieren, danach wieder über den Launcher arbeiten. Das gilt für jede App mit eigenem Updater; was aus dem App Store kommt, aktualisiert ohnehin der App Store.

Eine App will sich neu anmelden, obwohl sie es gestern schon war. Dann fehlt ihr der Schlüsselbund. In der Aufzeichnung steht dafür kein Pfad, sondern eine Zeile mit authorization-right-obtain - deshalb ist es leicht zu übersehen. Bei den Apps, die BX kennt, ist der Schlüsselbund freigegeben; bei einer selbst gewählten App hilft die Regel RW: ~/Library/Keychains für diesen Launcher. BX fragt vorher nach, denn in dieser Datei liegen alle Passwörter deines Macs.

Ein Werkzeug scheitert unter ~/Library. Eine Sitzung darf dort nur schreiben, was Programme im Normalbetrieb wirklich schreiben: Caches, Logs und den gesicherten Fensterzustand. Schriften, Farbprofile und Einstellungen sind lesbar, aber nicht änderbar - die Einstellungsdatei der gestarteten App selbst bleibt beschreibbar. Ganz zu sind die Cookie-Speicher, Eingabemethoden, Tastaturbelegungen und Skript-Ordner fremder Apps, denn wer dort schreiben darf, liest fremde Anmeldungen mit oder schleust Code in andere Programme ein. Braucht ein Werkzeug doch einen dieser Orte, zeigt die Aufzeichnung den genauen Pfad, und eine RW:-Zeile im Launcher gibt ihn gezielt frei - den Pfad aus der Aufzeichnung, nicht gleich den ganzen Ordner.

Ein Programm baut sich seine eigene Sandbox und scheitert daran. Zwei Sandboxen lassen sich nicht stapeln - was schon abgeschottet läuft, kann nichts weiter abschotten. Am ehesten begegnet dir das in Xcode: Beim Laden von Swift-Paketen meldet es “sandbox-exec: sandbox_apply: Operation not permitted”, einmal je Paket, und lädt keines davon. Das ist kein Zugriffsproblem, und keine Regel hilft dagegen. Xcode hat für diesen Fall einen Schalter - im Terminal eingeben und Xcode neu starten:

defaults write com.apple.dt.Xcode IDEPackageSupportDisableManifestSandbox -bool YES

Die Sandbox von BX bleibt dabei bestehen; du gibst nur Xcodes eigene, feinere Abschottung auf - dieselbe Abwägung wie bei Electron-Apps. Der andere Weg ist, Xcode gar nicht über einen Launcher zu starten: Es ruft ohnehin Compiler und Testläufe mit deinen vollen Rechten auf, der Schutz wiegt dort also wenig gegen den Aufwand.

Ein Launcher, dessen App du gewechselt hast, hat noch die Regeln der alten App. BX legt die Regeln für eine App einmal an und räumt sie nie von selbst wieder weg - du könntest sie geändert haben, und du könntest den Launcher auch zurückstellen. Nach einem Wechsel lohnt deshalb der Blick in die Regeln des Launchers: Startet ein früherer VS-Code-Launcher jetzt eine andere App, sieht die weiterhin ~/.claude und ~/.gemini, also die Anmeldung deines Coding-Agenten und den Verlauf aller Projekte, die er gesehen hat. Solche Blöcke sind mit # bx:defaults und dem Namen der App gekennzeichnet und dürfen weg.

Regeln in ~/.bxignore gelten für jeden Launcher. Das ist der bequeme Ort für eine Freigabe und der falsche: Eine Zeile dort bekommt jede Sitzung, auch die App, die damit nichts zu tun hat. Ein Projektordner gehört in den Launcher, der damit arbeitet.

Eine Regel auf eine Einstellungsdatei reicht oft nicht. Viele Programme speichern, indem sie daneben eine .lock- und eine .tmp-Datei anlegen und diese dann über das Original schieben. RW: ~/.foo.json deckt keinen dieser Schreibvorgänge ab, und die Einstellungen gehen still verloren. Nimm ein Muster: RW: ~/.foo.*.

Ein Paketmanager lädt plötzlich alles ein zweites Mal. pnpm sucht den Ort für seinen Paketspeicher, indem es ausprobiert, wohin es schreiben darf. Der Speicher selbst ist offen, der Ordner darüber aber nicht: Dort liegen die Programme, die deine Shell beim Namen aufruft, und die darf eine Sitzung nicht austauschen. Der Test scheitert deshalb, und pnpm legt sich einen zweiten Speicher als .pnpm-store mitten im Projekt an - jedes Paket noch einmal geladen und noch einmal auf der Platte. Abhilfe ist eine Zeile in ~/.npmrc, die den Ort ausdrücklich nennt, mit vollem Pfad statt ~:

store-dir=/Users/DEINNAME/Library/pnpm/store

Das .pnpm-store im Projekt darf danach weg; die schon installierten Pakete daneben bleiben nutzbar.

Ein gesperrter Ordner heißt nicht, dass die Daten unerreichbar sind. Dieselben Inhalte liegen oft noch woanders im selben Projekt. Sperrst du secrets/, liegt die eingecheckte Fassung weiterhin in .git und lässt sich von dort lesen - ein Muster auf Dateinamen greift daneben, weil Git die Inhalte unter eigenen Namen ablegt. Ein KI-Agent probiert genau solche Wege aus, wenn ihm ein Zugriff fehlt. Was eine Sitzung wirklich nicht sehen soll, gehört nicht in den Ordner, den sie geöffnet bekommt.

Der Papierkorb ist zu, also entsteht einer im Projekt. Dein Papierkorb liegt im Benutzerordner und damit hinter der Wand. Was eine Sitzung löscht, landet deshalb in einem .Trash-Ordner im Projekt selbst - der gehört dann zum Projekt wie jeder andere Ordner.

Der Ordner deines KI-Agenten ist ein Archiv. In ~/.claude und seinen Geschwistern liegt nicht nur die Anmeldung, sondern der Verlauf, und darin stehen Ausschnitte aus allem, was der Agent gelesen hat. Wer denselben Ordner zwei Launchern gibt, verbindet damit auch deren Projekte: Was in dem einen gelesen wurde, ist aus dem anderen nachlesbar.

Zwei Editoren nebeneinander. Wenn du denselben Editor mal abgeschottet und mal frei brauchst, installiere ihn zweimal - etwa Visual Studio Code für die freie Arbeit und VSCodium, die Community-Variante, im Launcher. Verschiedene Akzentfarben eingestellt, und du siehst am Fenster, worin du gerade arbeitest. Die Menüleiste sagt es dir ebenfalls, siehe Sandbox-Status.

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. Und sie können deinen Benutzerordner nur sperren, nie öffnen: eine Zeile wie RO: ~/.ssh in einer solchen Datei - etwa aus einem geklonten Projekt - bleibt folgenlos. Öffnen können nur die drei Stellen davor.

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.

Wie weit eine Sperrzeile reicht. secrets/ in ~/.bxignore sperrt ~/secrets, jeden so benannten Ordner in deinen Projektordnern und auch alles, was eine Sitzung ohne Regel bekommt: die Werkzeug-Ordner (~/.config, ~/.local und ihresgleichen), die Datenordner der gestarteten App und - wo freigegeben - den Schlüsselbund. Meinst du genau einen Pfad in deinem Benutzerordner, schreib ihn mit Tilde: ~/.config/gh ist dieser Ordner und sonst nichts.

Zwei Zugangsdaten sind ohne dein Zutun zu. Die Anmeldungen der Kommandozeilenwerkzeuge von GitHub (~/.config/gh) und Google Cloud (~/.config/gcloud) liegen in einem Werkzeug-Ordner, den jede Sitzung bekommt - BX nimmt sie wieder heraus. Brauchst du gh in einer Sitzung, öffnet die Zeile RW: ~/.config/gh es wieder.

Alle vier Stellen liest BX bei jedem Start einer Sitzung neu. Eine Zeile, die du von Hand einträgst, gilt also ab der nächsten Sitzung - ohne BX neu zu starten. Was du dabei in eine Regeldatei schreibst, bleibt auch dann stehen, wenn das Launcher-Fenster nebenher offen ist: BX überschreibt deine Änderung nicht, sondern übernimmt sie ins Fenster.

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 Einstellungen > 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 Einstellungen > Befehl 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]        zeigen, was die Sitzung dürfte
bx dry <mode> [ordner...] --sbpl           ... als Sandbox-Profil (gekaufte Version)
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

bx dry zeigt ohne Zusatz einen Baum und mit --rules dieselbe Auskunft als Regelzeilen; beides steht immer offen. --sbpl gibt das fertige Sandbox-Profil aus, so wie das System es liest, und gehört wie der Platz im Dock zur gekauften Version.

Unter Shell-Aliase 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 Alle Regeln zeigen… im Menü Dateien 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 Einstellungen > Allgemein stellst du ein, ob BX beim Anmelden startet und ob es überhaupt in der Menüleiste sitzt.

Sandbox-Status

Das Symbol selbst trägt diese Auskunft, ohne dass du es öffnen musst - ein grüner Punkt für eine laufende BX-Sitzung, ein gelber Ring, 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.

Wie weit das gehen soll, entscheidet Sandbox-Status unter Einstellungen > Allgemein: Sitzungen markiert nur, was in BX läuft, Apps mit Launcher zusätzlich den Fall oben, Alles ohne Sandbox jede weitere ungeschützte App - auf einem Mac sind das die meisten. Aus schaltet das Ganze ab; dann 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, und benennt ein Werkzeug, für das ein Launcher besteht und das dort ohne Schutz läuft. Diese Auskunft gilt für das ganze Fenster und nicht für den einzelnen Tab: welcher Tab gerade vorn ist, weiß nur das Terminal selbst, und BX fragt es nicht danach.

Einstellungen

• Allgemein - Start beim Anmelden (BX kommt dann ohne Fenster hoch und lebt in der Menüleiste), Symbol in der Menüleiste, Sandbox-Status.
• Sandbox - mit welchem Editor Regeldateien geöffnet werden.
• Befehl - in welchem Terminal Kommandozeilen-Launcher öffnen, der Befehl bx und die Shell-Aliase der Launcher. Ein einzelner Launcher kann woanders öffnen, siehe Terminal.
• Datenschutz - Absturzberichte ein- und ausschalten, was eine Update-Prüfung sendet, und “Support kontaktieren…”.
• Updates - Updates automatisch laden, am Beta-Programm teilnehmen, sofort nach einer neuen Version sehen.
• Lizenz - 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 und Compiler funktionieren weiter. Welche Prozesse eine Sitzung starten darf, ist nicht eingeschränkt.
• Wie weit die Sitzung ins Netz reicht, entscheidet Netzwerk im Launcher. Voreingestellt ist voller Zugriff; einzelne Gegenstellen lassen sich nicht freigeben.

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. Dasselbe trifft jedes Programm, das selbst eine Sandbox aufbaut - etwa Xcode beim Laden von Swift-Paketen.

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 Einstellungen > Datenschutz, 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 kannst du jeden Anhang 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 Einstellungen > Lizenz ein: