HN 표시: Bx – AI 및 코딩 도구를 위한 macOS 기본 샌드박스

Put your AI in a box. Launch VSCode, Claude Code, a terminal, or any command in a macOS sandbox — your tools can only see the project you're working on. Not a vault, but a reasonable safety net. AI-powered coding tools like Claude Code, Copilot, or Cline run with broad file system access. A misguided tool call or hallucinated path could accidentally read your SSH keys, credentials, tax documents, or private photos. bx wraps any application in a macOS sandbox (sandbox-exec ) that blocks access to everything except the project directory you explicitly specify. No containers, no VMs, no setup — just one command. bx ~/work/my-project That's it. 🎉 VSCode opens with full access to ~/work/my-project and nothing else. Read the blog post for more background on the motivation behind bx. Need multiple directories? No problem: bx ~/work/my-project ~/work/shared-lib - 🔒 Blocks ~/Documents ,~/Desktop ,~/Downloads , and all other personal folders - 🚧 Blocks sibling projects — only the directory you specify is accessible - 🛡️ Protects sensitive dotdirs like ~/.ssh ,~/.gnupg ,~/.docker ,~/.cargo - 🏛️ Opinionated protection for ~/Library — blocks privacy-sensitive subdirectories (Mail, Messages, Photos, Safari, Contacts, …) and containers of password managers/finance apps, while keeping tooling-relevant paths accessible - ⚙️ Keeps VSCode, extensions, shell, Node.js, and other tooling fully functional - 🔍 Generates sandbox rules dynamically based on your actual $HOME contents - 📝 Supports .bxignore files (searched recursively) to hide secrets like.env files within a project - 📂 Supports rw: andro: prefixes in~/.bxignore to grant read-write or read-only access to extra directories - 🗂️ Supports multiple working directories in a single sandbox - No network restrictions — API calls, git push/pull, npm install all work normally - No process isolation — this is file-level sandboxing, not a container - No protection against root/sudo — the sandbox applies to the user-level process - macOS only — relies on sandbox-exec (Apple-specific) - Not dynamic — the sandbox profile is a snapshot of $HOME at launch time; directories or files created later are not automatically blocked - File names visible — blocked files cannot be read or written, but their names still appear in directory listings (a kernel-level readdir constraint, same aschmod 000 ) - Not a vault — this is a safety net, not airtight isolation (see Security model) bx uses an allow-first / blocklist approach: everything is accessible by default, and only sensitive paths are explicitly blocked. This is the opposite of a deny-first / allowlist model where everything is blocked and only specific paths are opened up. Why allow-first? Developer tools require access to an enormous and ever-changing set of paths -- dotfiles, ~/Library , runtimes, caches, toolchains. A deny-first model would require new allow rules for every tool or framework update, breaking silently when a path is missing. The allow-first model works out of the box without per-tool tuning. What this means in practice: - bx provides reasonable protection against accidental or misguided file access -- not airtight isolation - Sensitive paths (credentials, personal data, other projects) are explicitly blocked - Paths that are not on the blocklist remain accessible -- including parts of ~/Library and most dotfiles - The sandbox profile is a snapshot at launch time -- files created later are not protected sandbox-exec itself is undocumented Apple API that could change with OS updates If you need stricter, deny-first isolation, consider Agent Safehouse or a Docker/VM-based approach (see Alternatives). bx is designed for the common case: keep AI tools and editors functional while blocking access to things they should never touch. # Homebrew brew install holtwick/tap/bx # npm npm install -g bx-mac # From source git clone https://github.com/holtwick/bx-mac.git cd bx-mac pnpm install && pnpm build pnpm link -g Requirements: macOS (only tested on Tahoe 26.4, feedback welcome), Node.js >= 22 | Command | What it launches | |---|---| bx [workdir...] | 🖥️ VSCode (default) | bx code [workdir...] | 🖥️ VSCode (explicit) | bx xcode [workdir...] [-- project-or-workspace] | 🛠️ Xcode | bx term [workdir...] | 💻 Sandboxed login shell ($SHELL -l ) | bx claude [workdir...] | 🤖 Claude Code CLI | bx exec [workdir...] -- cmd | ⚡ Any command you want | bx [workdir...] [-- app-args...] | 🔌 Any app from ~/.bxconfig.toml | If no directory is given, the current directory is used. All modes accept multiple directories. For app modes, values before -- define the sandbox scope (workdir... ). Values after -- are passed to the app as launch arguments. For xcode , this distinction is important: the sandbox workdir is not passed as an Xcode open argument. Use -- if you want to open a specific .xcworkspace or .xcodeproj . This behavior is configurable per app via passPaths in ~/.bxconfig.toml (default: true , built-in xcode default: false ). GUI app modes ar