cursor auto review 怎么用 工具审批三模式
cursor auto review 怎么用：Approvals 三模式、allowlist 与 classifier 分流，及 permissions.json 边界。
Agent 每跑一条 shell 都弹审批，长任务会被点麻；全放行又怕误删目录。cursor auto review 怎么用：在 Settings → Agents → Approvals & Execution 选 Auto-review，让 allowlist 与 classifier 分流，而不是手点每一次。
Run Modes 三个档位
Run Modes 文档 定义三档：
| 模式 | 行为概要 |
|---|---|
| Auto-review | allowlist 立即执行；可沙箱的 shell 进沙箱；其余走 classifier 审一下 |
| Allowlist | 仅 allowlist 内自动跑，其它每次问你 |
| Run Everything | 尽量全自动（风险最高） |
3.6 changelog（2026-05-29） 把 Auto-review 标为新的默认推荐，并说明旧版 Ask Every Time 已弃用。若你升级后仍每步都要点，先打开 Settings 确认不是卡在 Allowlist。
Cloud Agents 不用 Run Modes。这套审批只作用于桌面 Agent 会话里本地触发的 Shell、MCP、Fetch 等。云端 VM 上的 agent 走另一套团队策略，别在本地调好 Auto-review 就以为 cloud 一样。Mobile Remote Control 遥控本机工具时，审批仍走本机 Run Modes 配置。
Auto-review 对 Shell / MCP / Fetch 怎么分流
官方逻辑分三条线：
- 命中 allowlist 的命令或 MCP 调用：立即执行，不弹窗。
- 可 sandbox 的 shell：进沙箱跑（读写范围受限，具体能力随版本更新）。
- 其余：交给 classifier 快速判断允不允许。文档写明 classifier 模型为 Claude Haiku 4.5 或 GPT-5.4 Mini，取决于你账号可用模型列表。
Classifier 不是人工复核，是毫秒级自动决策；误判仍可能发生，所以文档强调 Run Modes 不是安全边界，不能替代代码审查或生产权限管控。Fetch 类工具（拉外部 URL）同样走这套分流，别只盯着 shell。
Enterprise 若配置了模型 ACL，界面上 Auto-review 可能变灰不可选，只能 Allowlist 或 Run Everything。这是策略锁，不是客户端 bug。灰掉时联系 admin 看是模型限制还是组织强制 Allowlist。
permissions.json 怎么写 allow / block
除 UI 勾选外，可在 ~/.cursor/permissions.json（用户级）或项目根的 .permissions.json 写规则。文档支持 allow_instructions 与 block_instructions，用自然语言描述允许或禁止的工具行为，与 allowlist 互补。
示例结构（字段名以 Run Modes 文档 当前说明为准）：
{
"allow_instructions": ["只读 git 状态与 diff", "npm test 但不 publish"],
"block_instructions": ["禁止 rm -rf", "禁止改 production 环境变量"]
}
改完保存，新会话生效；旧会话可能仍缓存旧策略，卡住时新开 Agent。Block 与 allow 冲突时，客户端倾向更安全一侧，具体解析以官方文档描述为准。
这与 Cloud Agent Hooks 不同：hooks 是事件脚本，Run Modes 是交互审批。本地 Agent 用 Run Modes；团队 cloud 用 Dashboard 与 hooks。两个文件不要混写：hooks 管 PR 事件，permissions 管本机工具审批。
选型建议与失效场景
个人日常开发：Auto-review 加上几条短 block_instructions（删库、推 main、改 .env）通常比 Allowlist 省点击，又比 Run Everything 稳。先把只读诊断命令加进 allowlist（git status、git diff、pnpm test --filter），classifier 误拦会少很多。
碰生产库或支付脚本：退回 Allowlist，或关键步骤手动跑，别指望 classifier 懂业务风险。CI 密钥所在目录建议在 block_instructions 里写死，即使用 Run Everything 也不该碰 .env.production。
Privacy Legacy 与合规：Run Modes 管的是「跑不跑命令」，不管数据存哪。若组织要求 No Storage，需另看 Cursor 隐私模式与国内团队 的策略，两者叠在一起才完整。
Classifier 误放行时：立刻加 block_instructions，临时切 Allowlist 直到规则收紧，并在 git 里 review Agent 刚跑的命令历史。Auto-review 提速的是审批 UX，不是零风险；敏感仓库仍应配合 branch protection、CI 与人工 review。
MCP 与 Fetch 在 Auto-review 下的表现
MCP 工具调用和 shell 一样分流：allowlist 里的 server 或 action 直跑；不在 list 里的走 classifier。Fetch 拉外部文档或 API 时，classifier 会看 URL 与动作是否像只读；误拦常见在「首次访问新域名」或「POST 非幂等接口」。把只读文档域名写进 allow_instructions 可减摩擦。
多个 MCP server 同时挂载时，block_instructions 宜写行为级禁止（「禁止写 Linear 以外工单系统」）而不是 server 名拼写，避免 rename 后规则失效。团队共享仓库时，把 .permissions.json 提交进 git，全员 Agent 行为一致；个人实验性 allow 放 ~/.cursor/permissions.json，别污染主分支。
升级 Cursor 后若审批行为突变，先看 changelog 是否改了 sandbox 或 classifier 模型，再 diff 你的 permissions 文件。3.6 弃用 Ask Every Time 后，老截图教程里的「每次都问」选项已不存在，Settings 里只剩三档 Run Mode。
Allowlist 模式适合「白名单极短、其余全人工」的合规场景：例如只允许 git diff 和 npm test，任何 npm install 都要你点确认。Run Everything 应限于 disposable 容器或本地 scratch 仓库；在主开发分支上长期开 Run Everything，一次误 git push --force 的代价远高于多点几次审批。Classifier 用的 Haiku / GPT-5.4 Mini 是轻量模型，复杂 shell 管道（嵌套 subshell、远程 SSH）更容易判错，这类命令宜预先写进 allowlist 或改用手动执行。
若你同时用 Cursor Automations 怎么用 跑云端流水线，记住 Automations 不受桌面 Run Modes 约束；本地 Agent 的 Auto-review 再严，也管不到云端 cron 触发的任务。两边策略要分开写：本地 permissions.json 管 IDE，Dashboard 管 cloud。
新同事 onboarding 时，建议在 repo README 里链一份 .permissions.json 样例，说明哪些 npm script 已在 allowlist、哪些必须人工点。Classifier 对 curl | bash 一类管道通常偏保守，文档下载脚本宜改成「先 wget 再 sh 本地文件」或写进 block。Windows 上 path 含空格时，allowlist 匹配行为可能与 macOS 不同，换平台后抽测两条命令再开长任务。
沙箱 shell 能挡一部分越权写盘，但不是虚拟机级隔离；文档原话是 Run Modes 不构成安全边界。生产 kubeconfig、云 CLI 默认 profile 不应指望 sandbox 替你兜底。若 Agent 频繁请求访问 ~/.ssh，应在 block_instructions 里明确禁止，并改用只读 deploy key。定期 export Settings 截图与 permissions 文件进 internal wiki，方便 audit 时对照「谁把 Run Everything 打开了」。Classifier 误判时可临时切 Allowlist 跑完关键一步再切回 Auto-review。