cusrsor auto run in sandbox

这是 Cursor 官方博客原文，技术细节非常清楚。下面给你完整的技术拆解：

Cursor Sandbox 技术细节

设计动机

Agent 越来越擅长执行终端命令，auto-approve 模式下能力显著增强，但风险也随之提升——Agent 可能误删数据库、提交错误代码、泄漏密钥。每次都要人工审批虽能降低风险，但随着并行 Agent 数量增多，工程师会产生"审批疲劳"，反而让审批失去意义。

Cursor 的解法是：让 Agent 在 sandbox 内自由运行，只有真正需要越界（最常见的是访问互联网）时才请求授权。生产数据显示，沙箱化的 Agent 停下来请求审批的次数减少了 40%。

核心设计原则

Cursor 暴露了一套统一的 sandbox API，但在每个平台下用不同的底层机制实现。

文件系统权限模型： Agent 对整个文件系统有读权限，但写权限只限于当前工作目录。网络调用受到限制。全局读权限是有意为之的——npm install 需要读取 ~/.npmrc 获取 registry 认证，Git 需要读 .gitconfig，AWS CLI 需要读 .aws/credentials，如果阻断这些读取，常规开发工具会直接失败。

三个平台的底层实现

macOS — Seatbelt（sandbox-exec）

Cursor 在 macOS 上评估了四种方案：App Sandbox、容器、虚拟机、Seatbelt。App Sandbox 要求对 Agent 可能执行的每个二进制文件都签名，会引入新的滥用向量。容器只支持 Linux 二进制。虚拟机的启动延迟和内存开销不可接受。最终选择了 Seatbelt，通过 sandbox-exec 访问。

Seatbelt 于 2007 年引入，2016 年被苹果标记为 deprecated，但 Chrome 等关键第三方应用至今仍在使用。它允许一条命令在 sandbox profile 约束下运行，这个 profile 会约束整个子进程树的行为。

Profile 通过一种特有的策略语言，以细粒度定义权限，限制 syscall 以及对特定文件和目录的读写。Cursor 在运行时根据 workspace 级别设置、管理员设置以及用户的 .cursorignore 动态生成该策略。

Cursor 官博给出了实际策略代码片段：

scheme
(deny file-write* (regex "^.*\/\\\.vscode($|\/.*)")
)
(deny file-write* (require-all
    (regex "^.*\/\\\.cursor($|\/.*)")
    (require-not (regex "^.*\/\\\.cursor/(rules|commands|worktrees|skills|agents)($|\/.*)")))
)
(deny file-write* (regex "^.*\\\.code-workspace$"))
(deny file-write* (regex "^.*\/\\\.cursorignore$"))
(deny file-write* (regex "^.*\/\\\.git/config$"))
(deny file-write* (regex "^.*\/\\\.git/hooks($|\/.*)")
)

注意这个策略允许写 .cursor/rules、commands、worktrees 等子目录，但禁止写 .cursor 根目录——Agent 可以修改自己的规则文件，但不能改 Cursor 的核心配置。

Linux — Landlock + seccomp

Linux 用内核暴露的 Landlock 和 seccomp 两个原语直接组合。seccomp 负责阻断不安全的 syscall，Landlock 负责执行文件系统限制，使被 ignore 的文件对沙箱进程完全不可访问。Cursor 把用户 workspace 映射进一个 overlay filesystem，并用 Landlock 锁定的副本覆盖被 ignore 的文件。

Linux 沙箱最慢的部分是找到并重新挂载这些文件。macOS 的 Seatbelt 可以在文件系统操作发生时懒过滤，但 Linux 的 seccomp-bpf 上下文里无法轻易获取文件路径，所以必须在沙箱启动前预先准备好 overlay。

Windows — WSL2

Windows 上直接在 WSL2 里运行 Linux sandbox。原生 Windows 沙箱机制几乎都是为浏览器定制的，不支持通用开发工具。Cursor 正在与微软合作，推动相关原语的开放。

Agent 如何感知自己在 sandbox 里

这个细节很关键，纯基础设施的沙箱没有用，模型本身也必须知道边界在哪。

Cursor 更新了 Shell tool 的 description，向模型说明沙箱约束：当前命令是否有文件系统访问权限、git 访问权限、网络访问权限（基于用户设置），以及如何在需要越权时请求提升权限。调整这个 harness prompt 需要大量手动测试——执行一批常见操作、观察哪里出乎意料地失败、调整 prompt、再跑一遍。

团队发现了一个常见失败模式：Agent 会在没有改变权限的情况下反复重试同一条命令。为此，Cursor 修改了 Shell tool 返回结果的渲染方式，明确显示是哪项沙箱约束导致了失败，在某些情况下还会建议 Agent 请求提升权限。加上这些提示后，Agent 从沙箱相关失败中恢复的能力显著改善。

网络访问的细粒度控制（2.5 版本新增）

沙箱现在支持细粒度的网络访问控制，以及对本地文件系统目录和文件的访问控制。用户可以通过 sandbox.json 定义 Agent 在沙箱内可以访问的域名白名单，分三档：仅用户配置的域名、用户配置加 Cursor 内置默认域名、完全不限制。企业版管理员可以从管理后台统一下发网络出口策略，覆盖所有 Agent session。

已知安全隐患（客观存在）

全局读权限带来的核心问题：~/.npmrc、~/.aws/credentials、~/.docker/config.json、~/.ssh 下的密钥，Agent 全部可以读取。Agent 不理解哪些文件是敏感的，它只看到可能帮助完成任务的文本。当 auto-approve 与全局读权限组合在一起时，敏感凭据可能出现在 Agent 的输出里。

这是 Cursor 沙箱目前最被诟病的权衡点，也是 NVIDIA 红队报告里列为残余风险的首条。

一句话总结技术栈： macOS 用 sandbox-exec（Seatbelt）动态生成策略文件；Linux 用 Landlock + seccomp-bpf + overlay filesystem 预挂载隔离；Windows 走 WSL2 复用 Linux 路径；策略文件基于 .cursorignore 和用户/管理员配置在运行时动态生成；模型侧通过修改 Shell tool description 和返回值渲染使 Agent 感知沙箱边界。