奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

Cursor 的 run modes：每一档各自放开了什么

2026-08-18

先把问题问具体一点：agent 在会话中间决定要执行一条终端命令，或者要调一个你接进来的 MCP 工具，从它「想调」到「真的跑起来」，中间到底经过了哪几道关？哪一道关会把你叫醒？

这件事在 Cursor 里由 run modes 决定。官方文档《Run Modes》页（cursor.com/docs/agent/security/run-modes）开头就把作用域框死了：run modes 控制 agent 怎么执行工具调用，以及什么时候打断你要求批准，用来决定 agent 在 shell 命令、MCP 工具和 Fetch 调用上拿到多少自主权。注意这个作用域——它管的是这三类调用，不是全部行为。

三档，各自放开到哪

文档给了一张模式表，回源数过一共 3 行：Auto-review、Allowlist、Run Everything。选择位置文档写明在桌面端的 Settings > Agents > Approvals & Execution（这是文档口径，不是我们看到的界面）。

模式文档写明「不问就跑」的范围sandboxclassifier
Auto-review允许清单内的调用立即执行；其它 shell 命令在可能时进 sandbox 执行；不走 sandbox 的调用交给 Auto-review classifier有，针对 shell 命令有
Allowlist只有你的允许清单里的动作免批准；开启 sandboxing 后，受支持的 shell 命令可以在 sandbox 里跑可选，针对 shell 命令无
Run Everything每一次工具调用都自动执行无无

文档对三档给出的适用场景分别是：想少弹窗但希望高风险调用先过一道安全审查；想要确定性的行为、只信任一小组重复动作；接受风险、要零打断。文档同时把 Auto-review 称作对多数人「最安全可用」的设置——这是文档自述的推荐，不是我们的评价。

Auto-review 那条链是怎么走的

这是本页最值得逐字读的一段。文档写明 Auto-review 作用于 shell、MCP 和 Fetch 三类工具调用，并且按这个顺序逐项检查：

  1. 命中允许清单的调用，立即执行；
  2. 其余 shell 命令，在可能的情况下放进 sandbox 执行；
  3. 不使用 sandbox 的调用，交给 classifier。

第 2 步里的「可能」有明确定义，不是模糊措辞：文档说一条 shell 命令「能在 sandbox 里跑」，指的是它能在 sandbox 的文件与网络限制下正常工作；那些需要完整系统访问权的命令——例如写到工作区之外、或者特权操作——没法被沙箱化，于是转交给 classifier。

第 3 步之后还有两条分支：classifier 拦下一个调用时，Cursor 可以让 agent 换一种做法；如果 agent 认为这个动作仍然合理，Cursor 会把批准提示弹给你。所以「被 classifier 挡了」不等于这条路彻底走不通，它可能绕一圈回到你手上。

文档专门用一个小节写了 Auto-review is not a security boundary：classifier 会出错，既可能放行你本来想拦的调用，也可能拦下你本来会放行的。这句话得原样带走，不要在心里把它翻译成「有审查所以安全」。

还有一个容易踩的依赖：classifier 跑在一个小型的、由 Cursor 托管的模型上。文档点了具体候选模型的名字，但模型清单属于随时变动的信息，这里不列。真正会咬到你的是它的后果——企业侧的 model access control 对此生效，只有当团队至少允许其中一个模型时 Auto-review 才可用；把它们全部屏蔽，Auto-review 在 Settings > Agents > Approvals & Execution 里就会被禁用，即使团队的 run modes 里包含它，成员也只能退回 Allowlist。文档给的处置动作是：在 Team Settings → Models 里放开对应模型，完全退出并重新打开 Cursor，再回去看 Approvals & Execution。

permissions.json 和 sandbox.json 不是一回事

Auto-review 读 permissions.json，文档列了两个位置：

位置作用范围
~/.cursor/permissions.json本机上所有项目目录
<project-dir>/.cursor/permissions.json单个项目目录，需要团队共用同一份指引时可以提交进仓库

两个文件同时存在时 Cursor 会合并，个人指引与项目指引都生效。但团队在 dashboard 里定义了全局 Auto-review 配置的话，团队配置优先，Cursor 会忽略用户级和项目级文件——排查「我本地明明写了却不生效」时先想这一条。

两份本地文件用同一套 schema，每条指令就是一句自然语言。文档给的示例原样如下：

{
  "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 描述希望它倾向于拦下的动作，被拦下后 agent 可以另选路径或者请你批准。注意用词是「倾向于」，文档没有把它写成硬规则。

sandbox.json 是另一回事。文档把分工写得很直白：permissions.json 决定 Auto-review 自动跑哪些调用、审查哪些；sandbox.json 控制一条被沙箱化的命令能够到什么，比如网络域名、额外的可读可写路径。两个文件都不是起步必需的。

默认沙箱行为文档也给了表，工作区内文件可读写（.cursorignore 可以把文件对 agent 藏起来）；.git/config、.git/hooks、.vscode、.cursorignore 以及敏感的 Cursor 配置文件属于受保护路径；网络默认阻断，再由网络模式和 sandbox.json 打开；/tmp 与平台临时目录默认可写，除非在 sandbox.json 里关掉。网络模式本身也是三档：只用 sandbox.json 允许清单、允许清单加上 Cursor 内置默认（文档写明这是默认值，随版本可能变动）、以及全部放开。文档附了一份内置默认域名清单，条目会随版本调整，需要时以官方文档为准。

sandbox.json 同样支持用户级与项目级两个位置，合并时项目级优先；此外团队管理员策略和 Cursor 内置的安全规则叠加在上层，本地文件无法削弱这些保护。这与 permissions.json 的「团队配置直接忽略本地」不是同一种优先级写法，两处别记混。

平台前提：Windows 侧文档没说

这一节对本站读者最要紧，所以说清楚边界。文档在「How sandboxing works on your platform」下只有两个小节：

  • macOS：通过 sandbox-exec 使用 Seatbelt，生成的 sandbox profile 对整棵子进程树限制文件访问、网络访问及其它进程行为。要求写明是 Cursor v2.0 或更新版本，无需额外设置。
  • Linux：使用 Landlock 与 seccomp，前者做文件系统限制，后者阻断不安全的系统调用。要求是内核 6.2 或更新且支持 Landlock v3（CONFIG_SECURITY_LANDLOCK=y），并启用 unprivileged user namespaces。内核不满足时，Cursor 会回落到执行命令前询问批准——这一条很实用，你以为在跑沙箱、实际在一路弹窗，多半就是它。

Windows 在这一页没有对应小节，环境变量表的 Platforms 列出现的也只有 macOS 与 Linux。所以「Windows 上 sandbox 怎么实现、能不能用」，官方文档在这一页没有说明，我们不做任何推断。对 Windows 上的使用者，这一页能确定的只有模式本身的语义：文档的模式表把 Allowlist 档的 sandbox 一栏写成「可选」，而 Auto-review 那一栏写的是「有，针对 shell 命令」；至于 Auto-review 里「其它 shell 命令在可能时进 sandbox」这一支在 Windows 上如何落地，这一页没有说明，需要以官方文档最新内容为准。permissions.json 的位置文档只给了 ~/.cursor/ 与 <project-dir>/.cursor/ 两种写法，没有单独列 Windows 路径写法。

另有一条只对远程环境和独立 CLI 生效的说明：本地桌面版安装无需额外设置，桌面包自带所需的 AppArmor profile；某些发行版通过 AppArmor 限制 user namespaces，而远程环境和独立 CLI 不带这个 profile，如果在那里创建沙箱时报 user-namespace 权限错误，需要安装对应发行版的 AppArmor 包，装完重启 Cursor 或 CLI 会话。

沙箱里的身份会变

Linux 上有个坑值得单独记：文档写明 sandbox 会创建 user namespace 并把进程在该命名空间内重映射为 UID 0，因此沙箱内 id -u 和 $UID 返回的是 0，不是你的宿主用户 ID。需要宿主身份的脚本（比如给 Docker 传 --user）应改读 Cursor 注入的环境变量。文档给出的示例原样如下：

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)} 这种回落写法保证命令在沙箱之外也能用，因为那时这些变量不会被设置。除了 CURSOR_ORIG_UID / CURSOR_ORIG_GID，文档还列了 CURSOR_SANDBOX（在沙箱内被设为 "seatbelt" 或 "native"）和仅 Linux 的 CURSOR_SANDBOX_LANDLOCK_STATUS（报告当前后端是 fully_enforced 还是 bubblewrap 回退，文档说它便于诊断）。想确认「我这条命令到底在不在沙箱里」，这两个变量是文档给出的可核对依据。

模式之外还有三道闸

文档明确说 run modes 和 sandboxing 不是全部的安全控制，另有 3 项 protection，即使当前模式本该自动执行也可能要求批准：Browser Protection（阻止 agent 自动运行 Browser 工具）、File-Deletion Protection（阻止自动删除文件，包含 rm 命令）、External-File Protection（阻止自动创建、修改或删除工作区之外的文件）。

再往外一层是《Agent Security》页（cursor.com/docs/agent/security）：读文件和搜代码不需要批准，可以用 .cursorignore 挡住特定文件；终端命令默认需要你批准，run modes 就是用来放开这一层的，该页把这些控制称为尽力而为的 guardrail 而不是硬性安全边界。MCP 这边更严一点：所有 MCP 连接需要批准，而且批准连接之后每次工具调用仍然要单独批准，可以用 MCP allowlist 预批准指定工具（格式见 cursor.com/docs/reference/permissions）。另外该页提醒，如果你开了自动重载，agent 的改动可能在你来得及审查之前就已生效。

两条历史变更与一个例外

changelog 里有两条会影响你按旧记忆找设置：3.5（2026-05-22）Ask Every Time 已被弃用（deprecated），新用户无法再选择它，文档给出的等价做法是使用 Allowlist 并把允许清单留空；同一版本里 Run in Sandbox 被并入了开启 sandboxing 的 Allowlist。3.6（2026-05-29）Auto-review 作为推荐默认发布。所以现在只剩三档，不是你印象里的更多档。

最后一个例外要记住：Cloud Agent 不使用 run modes。文档写明 run modes 只作用于本地 agent，Cloud Agent 跑在自己的专用机器上，因此不会向你索要动作批准。把本地这套授权直觉套到云端会算错风险面。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。 该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。 该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。 本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员