Only what you allow. Not your whole Mac.

Your apps see your project and nothing else

BX starts apps you already have - Claude, Claude Code, Cursor, VS Code, your terminal - inside a sandbox macOS brings along itself. You say which folder the app should work in. Everything else in your home directory is not locked away from it, it is simply not there: credentials, SSH keys, shell history, mail, messages, password managers.

No virtual machine, no container, no change to the app. Same apps, same folders, same workflow - only the field of view is smaller.

Set up once, then one click

Three questions and the launcher is done: which app, which folder, what to call it. From then on you start it from the BX window, from the menu bar, with an icon in the Dock, or by typing its name in a terminal.

The app comes up the way you know it. BX works out where it keeps its own settings and hands exactly those back: no editor behaving as if it had just been installed, no lost logins, no extensions to set up again.

If you use Claude and other AI tools

You do not have to write code for this to matter. An AI app that can read files reads them with your rights, and so does everything it starts. A single “have a look in my folder” is enough to put your tax documents, your mail archive and your password database within reach.

Give it a launcher instead. It gets the folder you meant, and nothing beyond it.

Two things worth knowing:

• Quit the app first. If it is already running unprotected, starting the launcher only opens a window in the process that is already there - silently, without a sandbox. BX’s menu bar item points that out.
• The value often sits in the extensions, not the app. An MCP server started as npx some-mcp-server is code from a stranger, running as a child process with your full rights. That is exactly what the sandbox is around.

The tools watch what gets written. BX watches what gets read.

The obvious pitch - “AI agents are unsafe” - is the wrong one. The accurate one is narrower and easier to check: the sandboxes these tools ship with barely cover the read side.

Claude Code sandboxes on macOS, and so do Codex CLI, Gemini CLI and Cursor. But the focus there is writes outside the working directory and network egress. Meanwhile ~/.ssh, ~/.aws, ~/.zsh_history, mail and password manager containers stay readable the whole time.

And each of those sandboxes only covers its own tool. The editor extension, an MCP server, a terminal an in-editor agent opens - all outside of it. BX sits one layer below and does not care what runs inside.

Seeing rather than guessing

This is the part a script does not have.

Before: the protection view shows, as a tree, what the session may read, what it may write and what it cannot see at all. Right-click to change it, for this one launcher or for all of them.

Afterwards: BX records what a session was turned away from and marks it exactly where it happened. When a tool misbehaves, the list says what it did not get - and a click hands it over. For sensitive places such as ~/.ssh, BX asks first.

That turns “the tool does nothing and I have no idea why” into a list with a button next to it. For the common programs it is done already: VS Code and its variants, JetBrains IDEs, Claude Desktop, ChatGPT, Xcode and a dozen command line agents come with what they need in order to run.

Not only AI

Everything you start reads with your rights, agent or not:

• Package installs and builds - pnpm install, pip install, cargo build, make, Gradle. Postinstall scripts are the most used dependency vector there is, and this happens daily.
• Mac-native toolchains that cannot be containerised - Swift, code signing, Fastlane. There is no Docker for these, and it is exactly where App Store Connect keys and signing identities live.
• Client separation in contract work - client A’s material stays out of reach while you work for client B. A contractual argument, not a fear-based one.
• Unfamiliar repositories - clone from GitHub and take a look. .vscode/tasks.json, .envrc, git hooks and the Makefile all run before you have read a line.

Any app that macOS does not already confine can go into a sandbox. For most of them it is not worth the trouble - for the ones that execute code you did not write, it is.

What you get

• Launchers. App, folder and rules in one place. Start from the window, from the menu bar, from the Dock, or as a word typed in a terminal.
• A policy you can read before you run it. The tree lists every folder the session may read and write. No guessing.
• The list of denied accesses where they happened - with a click to grant them.
• Rules as readable text files. .bxignore, in gitignore syntax, with comments and under version control - globally, per launcher or per project tree.
• A menu bar that says what you are working in. Protected by BX, by a sandbox of its own, or not at all - plus a warning when a tool runs unprotected although a launcher for it exists.
• The same engine on the command line. bx run, bx dry, bx list - and every launcher under a short name of its own.

Common apps are recognised automatically, including the Electron quirks that would otherwise keep them from starting. Only what is really installed on your Mac is offered.

Where the protection ends

BX is a file system read filter. A session may still run anything and reach the network - it simply sees less.

Seatbelt escapes are documented, and whatever a process can read it can also transmit. That covers the realistic problem, which is not a targeted attacker but a tool that reads more than it needs to and forwards it somewhere. Running deliberately malicious software is not what BX is for.

There is also nothing to gain for apps that already carry Apple’s own sandbox - they cannot take a second one. BX does not even offer them for selection.

Try it, then buy it

BX runs unchanged for three days. After that it protects exactly as it did before: every launcher keeps its sandbox, every rule keeps applying, it only says once per session that it would like to be paid for. The protection is never behind the paywall - what comes with the purchase is marked with a small cart and saves clicks, not exposure.

A one-off purchase, no subscription. macOS 14 or newer is required.

Origin

The concept, the protection rules and the .bxignore format come from the command line tool bx-mac (MIT). The app is a full Swift port of that engine - no Node, no separate installation, the same rule files.