《Cursor文档》-运行模式

运行模式决定 Cursor 智能体如何执行工具调用，以及 Cursor 会在何时中断并请求您批准。

您可以通过它们决定智能体在执行 shell 命令、MCP 工具和 Fetch 调用时拥有多大的自主权。对大多数人来说，最安全且实用的设置是 Auto-review 模式。它会执行已知安全的调用，在可能的情况下将 shell 命令置于沙盒中运行，并让分类器评审其他操作。

选择模式¶

在桌面端应用中，前往 设置 > 代理 > 批准与执行。

Auto-review 模式的工作原理¶

Auto-review 模式适用于 shell、MCP 和 Fetch 工具调用。Cursor 会按以下顺序检查每个调用：

如果 shell 命令在沙盒的文件和网络限制下能够正常运行，就表示它“可以在沙盒中运行”。需要完整系统访问权限的命令，例如在工作区外写入或执行特权操作，无法在沙盒中运行，因此会交由分类器处理。

对于 shell 命令，沙盒机制是运行模式之上的一层机制。它控制受支持的终端命令在哪里运行，而不决定该模式是否使用 Auto-review 模式分类器。

当分类器阻止某个调用时，Cursor 可以尝试其他方法。如果智能体认为尽管分类器作出了这一判断，该操作仍然合理，Cursor 会向你显示批准提示。

Auto-review 模式并非安全边界¶

分类器可能会出错。它可能允许原本你会阻止的调用，也可能阻止原本你会允许的调用。

Auto-review 分类器要求¶

Auto-review 模式的分类器使用小型 Cursor 托管模型运行。目前为 Claude 4.5 Haiku 或 GPT-5.4 Mini。

企业版模型访问控制适用。团队获准使用上述任一模型时，即可使用 Auto-review 模式。即使团队的运行模式中包含 Auto-review 模式，若所有这些模型均被阻止，设置 > agents > 批准与执行中的 Auto-review 模式也会被禁用。成员将改用允许列表。

如果 Auto-review 模式显示为灰色，请在团队设置 → 模型中启用这些模型，完全退出并重新打开 Cursor，然后再次检查“批准与执行”。

配置 Auto-review 模式¶

Auto-review 模式无需配置即可正常运行。如果有某些操作您始终希望手动评审，可以用自然语言描述这些操作。

最简单的设置方式是让 Cursor 智能体完成。您可以对它说：“我希望每条 AWS CLI 命令都先获得批准”，它会为您编辑 permissions.json。

您也可以自行编辑该文件。Auto-review 模式会从以下两个位置读取 permissions.json：

如果两个文件都存在，Cursor 会将其合并。您的个人指令和项目指令都会生效。

团队也可以在仪表盘中定义全局 Auto-review 模式配置。定义团队配置后，其优先级更高，Cursor 会忽略用户级和项目级文件。

两个本地文件使用相同的 schema。每条指令都是一句自然语言，因此，“我希望每条 AWS CLI 命令都先获得批准”这样的请求会直接映射到 block_instructions：

{
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Every AWS CLI command should go through approval first.",
      "Every command that modifies Kubernetes resources should go through approval first."
    ]
  }
}

• allow_instructions 用于描述 Auto-review 应优先允许的操作。
• block_instructions 用于描述 Auto-review 应优先阻止的操作，以便智能体选择其他路径或请求你批准。

有关策略设计的更多信息，请参阅使用 Auto-review 管理智能体自主性。

沙盒机制¶

沙盒机制让 Cursor 能够运行终端命令，而无需授予其对机器的完全访问权限。沙盒中的命令可以在项目内运行，但不能随意读取受保护的文件、写入获准路径之外的位置，或连接任意网络目标。

如需深入了解工程实现，请阅读为本地智能体实现安全沙盒。

permissions.json 和 sandbox.json 的作用不同¶

permissions.json 决定 Auto-review 自动执行哪些调用、评审哪些调用。sandbox.json 控制沙盒中的命令可访问哪些资源，例如网络域名以及额外的可读写路径。快速入门无需使用这两个文件。

有些命令需要完全的系统访问权限，因此会绕过沙盒。命令在沙盒外运行时，Cursor 会提示你并请求批准。

沙箱配置¶

通过 sandbox.json 文件自定义沙箱行为：

如果两个文件都存在，Cursor 会合并它们，并以项目级文件为准。团队管理员策略和 Cursor 内置的硬性安全规则会叠加生效，因此本地文件无法削弱这些保护措施。

使用 sandbox.json 控制网络策略、额外的可读或可写路径、临时目录写入和共享构建缓存。完整 schema 请参阅 sandbox.json 参考。

沙箱如何在您的平台上运行¶

macOS¶

Cursor 通过 sandbox-exec 使用 Seatbelt。生成的沙箱配置文件会限制整个子进程树的文件访问、网络访问及其他进程行为。

要求

• Cursor v2.0 或更高版本
• 无需额外设置

Linux¶

Cursor 使用 Landlock 和 seccomp。Landlock 用于限制文件系统访问。seccomp 会阻止不安全的系统调用。

要求

• 内核 6.2 或更高版本，且支持 Landlock v3 (CONFIG_SECURITY_LANDLOCK=y)
• 已启用非特权用户命名空间

如果您的内核不满足这些要求，Cursor 会改为在运行命令前请求批准。

AppArmor 设置（仅限远程环境和 CLI）¶

本地桌面端安装无需设置。Cursor 桌面端软件包附带所需的 AppArmor 配置文件。

某些发行版会通过 AppArmor 限制用户命名空间，而远程环境和独立 CLI 不附带该配置文件。如果在这些环境中创建沙箱失败，并出现用户命名空间权限错误，请安装适用于您的发行版的 AppArmor 软件包。

Debian / Ubuntu：

curl -fsSL https://downloads.cursor.com/lab/enterprise/cursor-sandbox-apparmor_0.6.0_all.deb -o cursor-sandbox-apparmor.deb
sudo dpkg -i cursor-sandbox-apparmor.deb

RHEL / Fedora：

curl -fsSL https://downloads.cursor.com/lab/enterprise/cursor-sandbox-apparmor-0.6.0-1.noarch.rpm -o cursor-sandbox-apparmor.rpm
sudo rpm -i cursor-sandbox-apparmor.rpm

安装后，请重新启动 Cursor 或 CLI 会话，使沙箱生效。

环境变量¶

Cursor 会向每个沙盒化子进程注入环境变量。沙盒内运行的脚本、构建工具和自动化均可使用这些变量。

Linux：沙盒内的 UID 可能与实际用户 UID 不一致¶

在 Linux 上，沙盒会创建用户命名空间，并将进程重新映射为该命名空间中的 UID 0
(root) 。因此，沙盒化命令中的 id -u 和 $UID 会返回 0，
而不是主机用户 ID。如果脚本或自动化需要主机用户 ID，例如设置文件所有权或向
Docker 传递 --user，请读取 CURSOR_ORIG_UID 和 CURSOR_ORIG_GID。

Docker 和容器自动化¶

自动化规则和脚本中常见的一种做法是运行需要与主机用户身份一致的 Docker 容器。由于沙盒会在 Linux 上重新映射 UID，使用 $(id -u) 会得到错误的值。请改用 CURSOR_ORIG_* 变量：

docker run --rm \
  --user "${CURSOR_ORIG_UID:-$(id -u)}:${CURSOR_ORIG_GID:-$(id -g)}" \
  -v "$PWD:/work" -w /work \
  my-image build

${CURSOR_ORIG_UID:-$(id -u)} 这一回退机制可确保该命令在沙箱外也能运行，因为此时变量未设置。

网络访问¶

选择受沙盒限制的终端命令访问网络的方式：

查看默认允许的域名¶

*.cloudflarestorage.com
*.docker.com
*.docker.io
*.googleapis.com
*.githubusercontent.com
*.gvt1.com
*.public.blob.vercel-storage.com
*.yarnpkg.com
alpinelinux.org
anaconda.com
apache.org
apt.llvm.org
archive.ubuntu.com
archlinux.org
awscli.amazonaws.com
azure.com
binaries.prisma.sh
bitbucket.org
centos.org
cloudflarestorage.com
cocoapods.org
codeload.github.com
cpan.org
crates.io
debian.org
dl.google.com
docker.com
docker.io
dot.net
dotnet.microsoft.com
eclipse.org
fedoraproject.org
files.pythonhosted.org
fonts.gstatic.com
gcr.io
ghcr.io
github.com
gitlab.com
golang.org
google.com
goproxy.io
gradle.org
haskell.org
hashicorp.com
hex.pm
index.crates.io
java.com
java.net
json-schema.org
json.schemastore.org
k8s.io
launchpad.net
maven.org
mcr.microsoft.com
metacpan.org
microsoft.com
mise.run
nodejs.org
npm.duckdb.org
npmjs.com
npmjs.org
nuget.org
oracle.com
packagecloud.io
packages.microsoft.com
packagist.org
pkg.go.dev
playwright.azureedge.net
ppa.launchpad.net
proxy.golang.org
pub.dev
public.blob.vercel-storage.com
public.ecr.aws
pypa.io
pypi.org
pypi.python.org
pythonhosted.org
quay.io
registry.npmjs.org
registry.yarnpkg.com
repo.maven.apache.org
ruby-lang.org
rubygems.org
rubyonrails.org
rustup.rs
rvm.io
security.ubuntu.com
sh.rustup.rs
sourceforge.net
spring.io
static.crates.io
static.rust-lang.org
sum.golang.org
swift.org
ubuntu.com
visualstudio.com
yarnpkg.com
ziglang.org

其他保护机制¶

运行模式和沙盒机制并非仅有的安全控制措施。即使某个模式本应自动运行，以下保护机制仍可能要求批准：

团队控制¶

管理员可以设置用户可用的模式，还可配置终端命令的沙盒网络规则等。所有这些设置均可在网页端仪表盘中管理。

团队设置优先于个人和项目配置。需要为所有成员设定统一的基准时，请使用这些设置。如果您为团队启用 Auto-review 模式，请确保在模型访问控制中允许分类器所需的模型之一。

更新日志¶

Cloud Agents 不使用运行模式¶

运行模式适用于本地智能体。Cloud Agents 在各自的专用机器上运行，因此智能体不会要求你批准操作。