AI 编码 Agent 文件访问权限太大怎么办?Bx 用 macOS 沙箱给每把工具划定项目边界
用 Claude Code、Cursor、Cline 这些 AI 编码工具写代码的时候,你有没有想过一个问题:它们能看到你电脑上所有的文件。
你的 SSH 私钥在 ~/.ssh 里,AWS 凭证在 ~/.aws,个人照片在 ~/Photos,税单在 ~/Documents——这些目录对 AI 编码工具来说完全是敞开的。一次错误的工具调用、一条幻觉路径,就可能让 AI 读到不该看的东西。
更糟的是,你在 Project A 上工作时,AI 工具也能看到隔壁 Project B 的代码。你是信任工具不犯错,还是信任自己不手抖?
其实不需要二选一。Bx(bx-mac)是一个 macOS 原生沙箱工具,用一行命令就能给任意应用划定文件访问边界——只看到你指定的项目目录,其他一概不可见。
Bx 解决了什么?
Bx 的思路很简单:在启动应用时包装一层 sandbox-exec(macOS 自带的沙箱机制),生成一份白名单/黑名单混合的安全规则,然后只有你指定的目录可读写,其余全部拦截。
bx ~/work/my-project
上面的命令会启动 VSCode(默认行为),但 VSCode 只能访问 ~/work/my-project——读不了 ~/.ssh,看不见 ~/Documents,也碰不到 ~/work/other-project。
需要多个目录?也没问题:
bx ~/work/my-project ~/work/shared-lib
安装:两条命令搞定
Bx 用 Node.js 编写,通过 Homebrew 或 npm 均可安装:
brew install holtwick/tap/bx npm install -g bx-mac
要求 macOS(已在 Tahoe 26.4 上测试)和 Node.js >= 22。
核心用法:五种模式
Bx 支持多种启动模式,覆盖大部分开发场景:
| 命令 | 功能 |
|---|---|
bx [目录...] | 启动 VSCode(默认模式) |
bx code [目录...] | 显式启动 VSCode |
bx claude [目录...] | 启动 Claude Code CLI |
bx term [目录...] | 启动受限的登录 shell |
bx exec [目录...] -- <命令> | 在沙箱中运行任意命令 |
比如让 Claude Code 只看到当前项目:
bx claude ~/work/my-project
想在隔离环境中跑个 Python 脚本?用 bx exec:
bx exec ~/work/my-project -- python train.py
安全模型:allow-first 策略
Bx 采用 allow-first(默认放行 + 黑名单) 策略:默认所有路径可访问,只有敏感路径被显式拦截。
为什么不用更严格的 deny-first(默认全封 + 白名单)?因为开发工具需要访问的路径实在太多了——dotfiles、~/Library、运行时缓存、工具链……deny-first 模型要求你为每个工具手动开路,漏一个就静默报错。
Bx 的 allow-first 策略覆盖了这些保护范围:
- Dotdirs:
.ssh、.gnupg、.docker、.cargo、.gradle、.gem - Library 个人目录:Mail、Messages、Photos、Safari、Contacts、Calendars、Cookies 等
- 密码管理器容器:1Password、Bitwarden、MoneyMoney 等
- 同级项目:你只指定一个工作目录,其他所有目录均不可见
可以用 --dry 预览哪些路径被保护、哪些可访问:
bx --dry ~/work/my-project
进阶配置:bxconfig 和 bxignore
自定义应用(bxconfig.toml)
不是只有 VSCode 和 Claude Code 能用 Bx。编辑 ~/.bxconfig.toml,可以用 bx 包装任何 macOS 应用:
[cursor] bundle = "com.todesktop.230313mzl4w4u92" binary = "Contents/MacOS/Cursor" [zed] path = "/Applications/Zed.app/Contents/MacOS/zed"
还可以创建别名来管理常用工作区:
[myproject] mode = "code" paths = ["~/work/my-project", "~/work/shared-lib"]
然后运行 bx myproject 即可打开 VSCode + 两个指定目录的沙箱。
项目级规则(bxignore)
.bxignore 文件放在项目目录中,可以隐藏敏感文件:
.env .env.* secrets/ *.pem *.key
Bx 会递归扫描项目目录下的所有 .bxignore——monorepo 的不同子项目可以各自定义隐藏规则。
全局规则
~/.bxignore 用于统一管理家目录级别的访问权限。除了隐藏规则,还可以用 rw: 和 ro: 前缀开放额外路径:
.aws .azure .kube rw:work/bin ro:reference/docs
安全边界:它不是什么
Bx 不是容器,也不是 VM。它有几个明确的能力边界:
- 不做网络限制——API 调用、
git push、npm install正常走 - 不做进程隔离——只做文件级沙箱
- 不防 root/sudo——沙箱只对用户级进程生效
- macOS only——依赖
sandbox-exec(Apple 私有 API) - 快照式保护——启动时扫描
$HOME生成规则,运行时新建的文件不会被自动拦截
换句话说,Bx 提供的是”合理的安全网”而非”气密隔离”。对于日常使用 AI 编码工具的场景而言,这正是我们需要的东西——阻止 AI 偶然读到不该读的文件,而不是把它关进铁笼。
与内置沙箱的互补关系
Claude Code、Codex CLI、VS Code Copilot 等工具已经内置了各自的沙箱机制。但每个工具只保护自己的运行环境——换一个工具就不生效了。Bx 在进程层面统一包装,让所有工具共享同一套文件访问策略。即使某个工具的内置沙箱关闭了、配错了、或压根没有,Bx 仍然在底层保护你的文件。
总结
Bx 解决的问题很具体:AI 编码工具的文件系统访问权限过大。它的解决方案也很简单:一行命令包装任意应用,让工具只看得到你指定的目录。
对于 macOS 上使用 Claude Code、Cursor、Cline 等 AI 编码工具的开发者,Bx 是一个低成本的”安全气囊”——装上它不会改变你的工作流,但你知道即使 AI 猜错了路径,你的 SSH 密钥也不会被误读。
相关链接