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

权限与运行模式对照：Claude Code 的 permission modes 与 Cursor 的 run modes

2026-08-18

不比谁的模型强。只问一个能落地的问题：agent 想跑一条 shell 命令、想改一个文件，这个动作在真正执行之前要过几道关？两边文档都把这条链写得挺细，但拆法完全不一样，按 A 的心智模型去用 B，多半会在某一处被咬。

依据只有双方公开文档：Claude Code 侧是 code.claude.com/docs 的 permission-modes、permissions、sandboxing 三页；Cursor 侧是 cursor.com/docs/agent/security/run-modes 与 cursor.com/docs/agent/security 两页。两个都是闭源产品，我们没有源码，也没有做过实测。

Claude Code：规则先行，模式决定剩下的怎么办

Claude Code 官方文档《Configure permissions》页把权限规则分成 allow、ask、deny 三类，求值顺序固定为 deny → ask → allow，第一条命中就定案，而且文档明写「规则的具体程度不改变这个顺序」。实际后果是：一条宽泛的 Bash(aws *) deny 会挡住更窄的 Bash(aws s3 ls) allow，deny 规则里写不了例外；ask 与 allow 之间同理。

规则之前还有一层。同一页写明 PreToolUse hook 在权限提示之前运行，覆盖除 EndConversation 之外的每个工具；但 hook 的返回值不能绕过规则——它返回 "allow"，命中的 deny 照样阻断，命中的 ask 照样提示。唯一的例外是 hook 以退出码 2 结束，文档说这会在权限规则被求值之前就停下调用，所以它能压过 allow 规则。

规则和 hook 都没命中，才轮到模式。《Choose a permission mode》页在「How the classifier evaluates actions」里给的判定顺序是四步，第一条命中者胜：命中 allow/ask/deny 规则的立即定案；只读动作与工作目录内的文件编辑自动放行；其余交给分类器；分类器拦下时 Claude 收到理由并尝试别的做法。两个例外写在同一处：写入 protected paths 的动作即使命中 allow 规则也仍走分类器；组织把 connector 工具设成 ask、以及标了 requiresUserInteraction 的 MCP 工具会跳过分类器直接提示你。

六个档位各自放开了什么

《Choose a permission mode》页列了六个模式。下面只保留「不问就能跑什么」这一列，因为这是选档时最直接影响你的一列：

模式不问就能跑的动作范围
default（CLI 里标为 Manual）只有读
acceptEdits读、文件编辑，以及常见的文件系统 Bash 命令
plan读；当 auto mode 可用时，另加分类器批准的命令
auto全部，带后台安全检查
dontAsk只有预先批准过的工具
bypassPermissions全部

acceptEdits 那一格值得展开，「常见的文件系统命令」这个说法容易让人低估它。文档在对应小节点了名：mkdir、touch、rm、rmdir、mv、cp、sed。也就是说 rm 在这一档里是自动放行的，前提是路径落在工作目录或 additionalDirectories 之内；带安全环境变量前缀（如 LANG=C）或进程包装器（timeout、nice、nohup）时同样自动放行。范围之外的路径、protected paths 的写入、以及内置只读命令集之外的其它 Bash 命令仍会提示。

dontAsk 的语义是「只跑预批过的，会话永不等输入」：只有命中 permissions.allow 的动作、内置只读 Bash 命令和 PreToolUse hook 批准的调用能跑，内置的 AskUserQuestion 与组织设成 ask 的 connector 工具即使被 allow 规则匹配也照拒。它从不出现在 Shift+Tab 轮换里，只能启动时指定：

claude --permission-mode dontAsk

bypassPermissions 不能从没启用它的会话中途进入，必须启动时启用。即便这一档，文档也列了仍会提示的几项：显式 ask 规则、组织设成 ask 的 connector 工具、标了 requiresUserInteraction 的 MCP 工具，以及针对根目录或家目录的删除（rm -rf /、rm -rf ~）作为熔断。

protected paths 是单独一层，各模式结果不同：default 与 acceptEdits 提示，plan 提示，auto 交给分类器，dontAsk 直接拒绝，bypassPermissions 放行。关键一句在表下面：settings 里的 permissions.allow 规则不能预批 protected-path 写入，因为这道检查跑在 allow 规则求值之前——你写 Edit(.claude/**) 不会改变上表任何一格。

Cursor：三档 run mode，Auto-review 里再走三步

Cursor 官方文档《Run Modes》页给了三档：Auto-review、Allowlist、Run Everything，并把 Auto-review 称作对多数人最安全可用的配置。按该页表格，Allowlist 下只有你 allowlist 里的动作免批准（启用沙箱时受支持的 shell 命令可以在沙箱里跑），Run Everything 下每个工具调用都自动执行。

同页 Changelog 有两条必须照实标出来：Ask Every Time 已被 deprecated，新用户不能再选，官方给的等价做法是「用 Allowlist 配一个空 allowlist」；Run in Sandbox 已被折叠进「启用沙箱的 Allowlist」。还在讲这两档的教程，讲的是旧版本。

Auto-review 的检查顺序作用于 shell、MCP、Fetch 三类调用：先看 allowlist，命中立即跑；否则 shell 命令在可以沙箱化时进沙箱；其余交给分类器。文档写明什么叫「可以沙箱化」——命令能在沙箱的文件与网络限制下工作就算；需要完整系统访问的（写工作区之外、特权操作）没法沙箱化，转给分类器。分类器拦下后的兜底也写了：Cursor 可以换一种做法；如果 agent 认为这动作仍然该做，Cursor 会弹批准提示给你。

模式之外还有三项保护，可以在模式本会自动放行时仍要求你批准：Browser Protection（挡自动运行浏览器工具）、File-Deletion Protection（挡自动删除文件，包括 rm 命令）、External-File Protection（挡自动创建、修改或删除工作区之外的文件）。

《Agent Security》页写明的默认盘是：读文件和搜代码不需要批准；工作区文件可无批准修改，但配置文件需先批准；终端命令默认需要你批准；MCP 连接需批准，而且批准连接之后每个工具调用仍要单独批准，可用 MCP allowlist 预批特定工具。

差异一：规则的形态

Claude Code 的规则是可静态匹配的语法：Tool 或 Tool(specifier)，Bash 规则支持任意位置的 *，路径规则用 gitignore 语义并区分四种锚点。Cursor 的 Auto-review 配置是另一路：《Run Modes》页写明 permissions.json 里 autoRun 下的 allow_instructions 与 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."
    ]
  }
}

文档对这两个字段的措辞是「倾向于放行」「倾向于拦下，好让 agent 换条路或者来问你」，用的是 lean toward，不是硬边界；同页有一节标题直接叫「Auto-review is not a security boundary」，正文说分类器会犯错。Claude Code 那边也没把话说满：auto mode 的警告写着它减少提示但不保证安全，permissions 页还专门警告靠 Bash 模式约束命令参数是脆弱的。

这个差异什么时候咬到你：你想表达一句「AWS 相关的都先问我」，Cursor 允许你直接写那句话，Claude Code 要你翻成规则语法并考虑复合命令与包装器；但反过来，要事后审计「这条命令为什么被放行」，Claude Code 的规则本地可静态判定并能列出来源文件，Cursor 的 instructions 是给分类器读的意图描述。

差异二：沙箱和「谁来批」的接缝

两边都把沙箱与审批分成两层，但接缝位置不同。

Claude Code 的《Configure the sandboxed Bash tool》页明说 /sandbox 不是 permission mode：模式决定一次调用跑不跑、要不要先问你，沙箱决定命令跑起来之后能碰什么。沙箱自己有两档（auto-allow 与 regular permissions），文档强调沙箱的 auto-allow 与权限模式的 auto mode 是两码事、互相独立、可叠加。有一条会改变日常提示频率的默认值：autoAllowBashIfSandboxed 默认为 true，于是即便在 Manual 模式下，能沙箱化的 Bash 命令也不提示直接跑，包括在沙箱边界内改文件的命令，而同样的改动走文件编辑工具是会提示的；plan 模式是这条的例外。

Cursor《Run Modes》页的表述是：sandboxing 是叠在 run mode 之上的一层，它决定受支持的终端命令在哪里跑，而不决定这个模式用不用分类器。沙箱默认盘该页也列了：工作区内可读写；.git/config、.git/hooks、.vscode、.cursorignore 与敏感 Cursor 配置文件属于受保护路径；网络默认封闭，再由网络模式与 sandbox.json 打开。文档另说明 permissions.json 与 sandbox.json 干两件事：前者管 Auto-review 自动跑哪些、复核哪些，后者管沙箱里的命令能够到什么。

同一条轴上的对照：rm 在 Claude Code 的 acceptEdits 里属于模式内自动放行的清单项，在 Cursor 这边则由一项独立的 File-Deletion Protection 专门挡、并点名包括 rm。两边把「删文件」放在了不同的层上。

差异三：Windows

Claude Code 的沙箱不支持原生 Windows。文档写得直接：沙箱跑在 macOS、Linux 和 WSL2 上，原生 Windows 与 WSL1 都不支持，Windows 上请在 WSL2 发行版里跑；给组织做管理配置那一节又重复了一遍。于是在原生 Windows 上，「沙箱边界替代提示」这条路径不存在，你能用的就是权限规则加模式。两条 Windows 特有的细节值得记：

一是 acceptEdits 在 PowerShell tool 启用时，会自动放行范围内路径上的 Set-Content、Add-Content、Clear-Content、Remove-Item 及常见别名；但文档明说位置参数里含引号字符的调用（它给的例子是 Set-Content .\notes.txt "It's done"）即便路径在范围内也仍然提示，理由是无法静态判定这种参数的两种读法哪个成立——改用 -Value 这样的具名参数传内容就不触发提示。

二是只读命令集在 Windows 上多一条提示条件：参数里带网络（UNC）路径的命令，比如 \\server\share\file，会提示，因为访问网络路径可能把你的 Windows 凭据发给它指名的主机；这条检查同样适用于 PowerShell tool 的命令。

Cursor 侧，《Run Modes》页的「How sandboxing works on your platform」只写了 macOS 与 Linux 两节（macOS 用 Seatbelt，要求 Cursor v2.0 或更高；Linux 用 Landlock 与 seccomp，要求内核 6.2 或更高并启用非特权 user namespace，不满足时回落到运行命令前先问你）。Windows 侧的沙箱行为，我们在这两页 Cursor 文档里没有找到对应说明，因此不比。

差异四：组织能锁到什么程度

Claude Code 的 managed settings 优先级最高，文档说没有任何其它层级（含命令行参数）能覆盖一条 managed 权限规则；禁档位有专门的键，permissions.disableAutoMode 与 permissions.disableBypassPermissionsMode 设成 "disable" 分别拿掉这两档，另有 allowManagedPermissionRulesOnly 让用户与项目 settings 不能再定义任何规则。

Cursor 侧，管理员在 web dashboard 里覆盖用户能用哪些模式、配置沙箱网络规则，团队配置优先于个人与项目配置；Auto-review 的团队级配置一旦定义就优先并使 Cursor 忽略用户级与项目级文件。沙箱那边则是合并语义：两级 sandbox.json 都存在时合并、项目级优先，团队策略与 Cursor 内置的硬编码安全规则叠在最上层，本地文件无法削弱它们。还有一条容易踩：Auto-review 的分类器跑在 Cursor 托管的小模型上，受企业 model access control 影响，把这些模型全禁掉会导致 Auto-review 不可用、成员只能退回 Allowlist（具体是哪些模型随版本变动，本文不列）。

明确不比的几项

  • 分类器的准确率、误拦率、延迟：两边都没有可核数据，不比。双方各自写了限定语（Cursor 说 Auto-review 不是安全边界，Claude Code 说 auto mode 不保证安全），这是文档自述的口径。
  • Cursor 有没有对应 plan 那样的「只读研究、批准计划后再动手」档位：我们在这两页 Cursor 文档里没有找到对应说明，不比。
  • Cursor 在 Windows 上的沙箱：同上，没有依据，不比。
  • Browser Protection 与 Claude Code 侧的浏览器相关拦截：Claude Code 那边是 auto 模式分类器默认拦截清单里的一条，Cursor 那边是一个独立的保护开关，两者所处的层不同，我们没有依据把它们放到同一条轴上比。

按你的处境挑

要无人值守跑 CI：Claude Code 的 dontAsk 是白名单制且永不等输入；Cursor 的 Run Everything 是零提示但不是白名单制；Cursor 文档另写明 Cloud Agents 不使用 Run Modes，它跑在自己的专用机器上，所以从不问你批准。这三件事不是一回事，选之前想清楚你要哪种。

要先看清楚再动手：Claude Code 用 plan，文档写明 Claude 会读文件、跑命令探索、写出计划但不改源码，批准计划后会话切到对应模式。Cursor 侧没依据，见上。

怕它动到仓库和编辑器配置：两边都有「不给自动放行」的路径清单，但生效层不同。Claude Code 的 protected paths 在权限层按模式表决定，allow 规则无法预批；沙箱另有一份自己的受保护路径，文档明说没有办法豁免其中任何一条，唯一关掉方式是把整个文件系统隔离层关掉。Cursor 的受保护路径写在沙箱默认行为表里，另有 External-File Protection 管工作区之外的文件。

你在 Windows 上：这一条往往比模式档位本身更能决定你怎么配。

怎么自己去核

别信任何二手表格，包括本文这几张。Claude Code 侧：/permissions 列出所有规则及其来源文件；claude auto-mode defaults 把分类器的完整默认规则清单打成 JSON；/sandbox 的 Config 标签展示解析后的沙箱设置；--verbose 能看到每次工具调用的确切参数名与值。

Cursor 侧：沙箱向每个子进程注入环境变量，CURSOR_SANDBOX 在进程处于沙箱内时被设置，Linux 上还有 CURSOR_SANDBOX_LANDLOCK_STATUS 报告当前生效的后端。另有一条 Linux 上的坑文档专门写了：沙箱会创建 user namespace 并把进程重映射到该命名空间内的 UID 0，所以沙箱里 id -u 和 $UID 返回 0 而不是你的真实用户 ID，需要真实 UID 的脚本要读 CURSOR_ORIG_UID 与 CURSOR_ORIG_GID。

两边的模式名、字段名与默认值都随版本变动，本文写到的每一条都请以官方文档最新内容为准。

本文依据 Claude Code 官方文档（code.claude.com/docs）于 2026-08-17 的公开内容整理。 该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。 该产品迭代频繁，文中涉及的命令、配置项与默认值随版本变动，请以官方文档最新内容为准。 本文不涉及价格、额度与限流的具体数值，相关信息请以官方定价与用量说明页为准。

本文涉及的另一方内容依据其官方文档整理（Cursor：cursor.com/docs）。 双方均为闭源商业产品，本文只对照各方公开写明的机制，不推断实现，也不对产品做优劣排名。

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

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

浏览课程 加入会员