Cursor 不弹确认就跑命令（YOLO / Auto-Run）

你把 auto-run 关了（或者压根没开过），打开 Agent 让 Cursor 做点无害的小事，下一秒就看到集成终端里 rm -rf node_modules 在跑，没有任何确认弹窗。又或者一长串 pip install。又或者直接 git push。你以为会弹确认，结果一声不吭。

最快的修法： 把 Run Mode 设成 Ask，这样每条 shell 调用都要你点同意。路径是 设置 → Cursor Settings → Agents → Run Mode，选 Ask，再把命令 allowlist 清空。常见情况一分钟内就搞定。本文剩下的部分，是给「这一步还压不住」的场景准备的。

先说一个最容易把人搞晕的命名变化：以前那个 YOLO mode 开关已经改名叫 Auto-Run；从 Cursor 3.6（2026 年 5 月 29 日发布）起，运行行为统一由一个 Run Mode 下拉框选择——Ask、Auto-review、Allowlist、Allowlist (with Sandbox)、Run Everything。新装的 Cursor 默认就是 Auto-review。 如果你没主动开过、但用的是全新的 3.6+ 安装，命令自己跑就是因为这个。

你属于哪一类？

症状	最可能的原因	跳到
全新 Cursor 3.6+，设置没动过	Auto-review 是新的默认 Run Mode	Step 1
只有 npm/git/python 这类命令不弹	allowlist 前缀太宽	Step 2
app 里设置看着是对的却没用	有个 .cursor/permissions.json 在覆盖	Step 3
你描述为「安全」的命令会跑，其它会问	Auto-review classifier 把它判成放行	Step 4
.cursorrules / .mdc 里写了「run without asking」	rule 在指示 Agent 跳过拦截	Step 5
只有计划的第一步弹了	多步计划继承了那一次同意	Step 6

常见原因

按命中率从高到低。

1. Run Mode 设成了 Auto-review 或 Run Everything

从 Cursor 3.6 起，Run Mode 决定 shell、MCP、Fetch 这些工具调用怎么拦：

• Ask —— 每条调用都等你点同意。你期待弹确认，就该选这个。
• Auto-review —— allowlist 内的立即跑，能 sandbox 的进 sandbox，其余全部交给一个 LLM classifier 子 agent 判断放行 / 换个方式 / 问你。这是新用户的默认值，所以全新安装会自己跑不少命令。
• Allowlist / Allowlist (with Sandbox) —— 只有 allowlist 内的自动跑，其余照样问。
• Run Everything —— 完全不拦（最接近老版 YOLO）。

怎么判断： 设置 → Cursor Settings → Agents → Run Mode。只要不是 Ask，就能解释为什么静默执行。

2. 命令 allowlist 太宽

Cursor 的 allowlist 是按前缀匹配的：git 会匹配 git status、git diff，也匹配 git push。很多人为了 npm test 加了一次 npm，忘了它把 npm uninstall 也一起带过。一个裸前缀或一个通配符，就意味着匹配到的命令不管看起来多无害都不弹。

怎么判断： 设置 → Cursor Settings → Agents → Command allowlist。任何单词前缀（npm、git、python）或通配符就是它。

3. 有个 permissions.json 在覆盖你的 app 设置

这是本文初版以来最大的变化。原来那套按 key 写的设置（cursor.agent.yoloMode、cursor.agent.allowedCommands）已经被 permissions.json 取代。Cursor 从两个位置读它：

• ~/.cursor/permissions.json（per-user，全局生效）
• <workspace>/.cursor/permissions.json（per-repo，只在该仓库生效）

一旦 permissions.json 定义了某个列表，它会完全取代 app 内对应类型的 allowlist，而且 app 里的编辑器会变成只读。所以你可能在 UI 上改了半天毫无效果，实际上是一个被 commit 进仓库的 workspace 文件在授权 auto-run。注意 per-user 和 per-repo 的数组是拼接的，所以仓库里的文件只能在你的基础上增加权限，不能删掉你的。

怎么判断： 在仓库和 home 目录里搜 permissions.json。如果 terminalAllowlist 里有宽前缀，或者 autoRun.allow_instructions 写得太松，它就盖过了 UI。

4. Auto-review 的 classifier 放行了它

在 Auto-review 下，你可以通过 permissions.json 里的 autoRun.allow_instructions / block_instructions 用自然语言去引导 classifier。如果你写了类似「allow build and test commands」，classifier 可能会把一条更宽的命令也判成符合你的意图而放行。Cursor 自己明确说 classifier 是非确定性的，是「best-effort convenience，不是安全边界」——它会漏判危险调用。

怎么判断： 看你的 autoRun instructions。如果写得宽泛或太理想化（「run whatever is needed」），就收紧它，或者把这个仓库切回 Ask。

5. Rules 文件里授权了自动执行

.cursorrules 或 .cursor/rules/*.mdc 里写了「always run shell commands without asking」这种话，Agent 把它当指令解析，会把 classifier 往「执行」那一侧推。

怎么判断： 在 rules 文件里 grep 「without asking」「no confirmation」「auto run」。命中任何一条都可能是它。

6. 命令排在多步计划里

Agent 经常先制定一个多步计划，整批一起跑。第一步可能弹确认，同一个计划里后面的步骤会继承那次同意、不再单独弹。

怎么判断： 看聊天记录。如果一开始有「Plan: 1, 2, 3」这种 block，你点了一次 Approve，后面的每一步都可能不再问。

开始前

• 想清楚要的是「零 auto-execute」（Run Mode 设 Ask）还是「小白名单」，修法不一样。
• 改设置前先把正在跑的 Agent 任务停掉——Run Mode 和 permissions.json 是每一轮开始时读的，跑到一半改没用。
• 改之前先记一下当前 permissions.json 的内容，方便回滚。

需要收集的信息

• Cursor 版本（Cursor → About Cursor；Windows/Linux 上是 Help → About）。截至 2026 年 6 月你应该在 3.6 或更新。
• 当前 Run Mode（设置 → Agents → Run Mode）。
• OS 和默认 shell（Cursor 集成终端用的是你的默认 shell）。
• 那条没弹就跑的命令原文。
• ~/.cursor/permissions.json 和仓库里 <repo>/.cursor/permissions.json 的内容。
• 项目里有没有 .cursorrules 或 .cursor/rules/*.mdc。
• workspace 里有没有 .vscode/settings.json（旧 key 可能残留）。

一步一步修复

Step 1：把 Run Mode 设成 Ask

设置 → Cursor Settings → Agents → Run Mode → Ask。这是最大的那根杠杆：Ask 模式下每条 shell、MCP、Fetch 调用都等你同意。如果你之前在 Auto-review（新默认）或 Run Everything，光这一步通常就修好了。改完 reload 窗口（Cmd/Ctrl+Shift+P → 「Developer: Reload Window」）。

Step 2：清空命令 allowlist

设置 → Cursor Settings → Agents → Command allowlist。一条不留全删掉。后面真要加，加完整字符串（npm test、pnpm build），别加裸前缀或通配符——记住是按前缀匹配的，git 会把 git push 也放行。

如果 app 里 allowlist 编辑器是只读的，说明有个 permissions.json 在控制它——去 Step 3。

Step 3：审 permissions.json（覆盖层）

把存在的文件都打开：

• ~/.cursor/permissions.json
• <你的仓库>/.cursor/permissions.json

一个安全锁死的文件长这样——allowlist 全空，再加上明确的 block 指令：

{
  "terminalAllowlist": [],
  "mcpAllowlist": [],
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Never delete files or directories (rm, rmdir, del).",
      "Never run git push, git reset --hard, or force operations.",
      "Never touch shell rc files, SSH config, or run package installs."
    ]
  }
}

因为 per-user 和 per-repo 的数组是拼接的，仓库里 commit 的文件只能在你的基础上加允许的命令——把它的 terminalAllowlist/autoRun.allow_instructions 条目删掉，或者把这个仓库的 Run Mode 设成 Ask。另外，settings.json 里老的 cursor.agent.yoloMode / cursor.agent.allowedCommands 这些 key 在 3.x 已经废弃了，残留的删掉，免得自己看花眼。

Step 4：收紧 Auto-review 的 classifier（如果你要继续用 Auto-review）

如果你想保留 Auto-review「少弹窗」的体验但行为更严，把 allow_instructions 限定到明确的低风险类别，再用 block_instructions 挡住所有破坏性操作（参考上面那段 block 列表）。把 classifier 当便利、不当安全——Cursor 自己也是这么说的。真正绝对不能误跑的仓库，就让它留在 Ask。

Step 5：清 rules 文件

grep 一下仓库里有没有 rule 在授权 auto-execute：

grep -ri "without asking\|no confirmation\|auto.run\|skip prompt" .cursor .cursorrules 2>/dev/null

命中的都删掉或重写。rules 是被当指令解析的，激进的 rule 会把 classifier 往「执行」那侧推。

Step 6：升级 Cursor

Cursor → Check for Updates。早期 0.x 版本有各种绕过确认的小毛病（比如 && 链式或 cd ... 前缀的命令溜过拦截）；3.6+ 的 Run Mode 模型把这些全部取代了。如果你落后太多，先升级再继续排查。

Step 7：拿一条已知无害的命令验证

随便找个 scratch 仓库问 Agent：「Run echo TEST && false」。在 Ask 模式下必须弹确认。还是静默跑，就回到 Step 1（Run Mode）和 Step 3（permissions.json 覆盖）。

Step 8：硬兜底——给 shell 套个 sandbox

确认门还是不可信的话，把 Cursor 集成终端指向一个 sandbox 包装脚本——所有不在安全列表里的命令都强制 stdin 输 yes/no：设置 → Terminal → Integrated → Default Profile。重了点但绝对兜底，而且不依赖任何 Cursor 设置。

怎么验证修好了

• 重新让 Agent 跑一个需要 shell 的 prompt，Ask 模式下确认弹窗必须出现。
• 让 Agent 跑一个多步计划，每一步 shell 都要弹，不是只弹第一步。
• reload 窗口再试一遍——Run Mode 和 permissions.json 要扛得住 reload。
• 重新打开 app 内 allowlist。如果你清空了它却是只读、还显示着条目，说明仍有个 permissions.json 在掌控。

长期预防

• 敏感仓库默认设 Ask；Auto-review 留给低风险、从零写的场景。
• terminalAllowlist 默认就保持空，没强理由不要加。
• 给共享仓库 commit 一个锁死的 .cursor/permissions.json（allowlist 全空 + block_instructions），让同事继承安全默认值。
• 把 .cursorrules 和 permissions.json 当代码看待——改了要走 PR review，别让 auto-run 那种 rule 或宽 allowlist 偷偷溜进来。
• 新人 onboarding 时把 user 和 workspace 配置都查一遍，clone 仓库的人会继承仓库里的 permissions.json。

容易踩的坑

• 以为 classifier 是安全边界。Cursor 明说它是「best-effort convenience，不是安全边界」。
• 为了 npm test 不弹，把 npm 加进 allowlist，忘了前缀匹配把 npm uninstall 也带过。
• app 里改 allowlist，结果有个 permissions.json 在默默盖掉它（发生时编辑器会变只读）。
• 指望仓库里的 permissions.json 去删掉你的权限——数组是拼接的，它只能加。
• 还在找老的 cursor.agent.yoloMode key。3.x 里没了，Run Mode + permissions.json 取代了它。

常见问答

• YOLO 模式去哪了？ 改名叫 Auto-Run 了，而且在 Cursor 3.6 里行为统一由 Run Mode 下拉框选（设置 → Agents）。想每次都弹就选 Ask。
• 为什么全新安装会自己跑命令？ 从 Cursor 3.6（2026 年 5 月 29 日）起，Auto-review 是新用户的默认 Run Mode。想要确认弹窗就切到 Ask。
• app 里 allowlist 不让我编辑，为什么？ 有个 permissions.json（~/.cursor/ 或仓库的 .cursor/）在定义这个列表，导致 app 里的编辑器变只读。改 JSON 就行。
• 能只白名单安全命令吗？ 能。在 terminalAllowlist 里用完整字符串如 npm test 或 pnpm build，别用裸前缀或通配符（匹配是按前缀的）。
• 这个门也拦文件编辑吗？ 不拦。文件编辑走 diff review 流程。Run Mode 和 allowlist 拦的是 shell、MCP、Fetch 这些工具调用。
• 为什么 Agent 没问就 push 到 main 了？ 要么 git 是 allowlist 前缀（它也匹配 git push），要么 Run Mode 是 Auto-review/Run Everything，要么你批准了一个包含 push 的多步计划。
• 有没有紧急停止键？ 点正在跑的任务上的 stop，或 Cmd/Ctrl+Shift+P → 「Cursor: Stop Agent」。失控进程直接 kill 集成终端。

相关

• Cursor Agent 模式工具调用卡住
• Cursor 终端命令出乎意料
• Cursor 配置冲突
• Cursor 规则没加载
• Cursor MCP server 连不上

外部参考：Cursor Agent Security 文档 和 permissions.json 参考。

标签: #Cursor #排查 #agent #排查

相关文章

常见问题解决库

Cursor Auto 把难任务路由给了弱模型 —— 完整修复指南

Cursor 的 Auto 路由把复杂重构发给小模型，结果改动浅。看懂路由信号，给难任务强制指定正确的模型。

2026/05/24 #Cursor #排查

常见问题解决库

Cursor 重启后聊天 / Composer 记录不见了

重开 Cursor 对话列表空了、只剩最近一条、或一直卡在 Loading Chat。多半是 workspace hash 变了、升级迁移出错，或 state.vscdb 损坏。怎么恢复 + 长期怎么防。

2026/05/24 #Cursor #composer

常见问题解决库

Cursor Cmd-K 内联编辑一直转、不出 diff 的修法

Cmd-K（Ctrl+K）一直转，或卡在 "Taking longer than expected…" 不出 diff。最快一招：Reload Window 或升级 Cursor。六类已验证根因逐一排查。

2026/05/24 #Cursor #排查

常见问题解决库

修复 Cursor 扩展：网络错误或商店列表空空

Cursor 扩展面板报网络错误、列表空空或 spinner 卡住。Cursor 用的是 Open VSX，不是微软商店。对症归类，快速解决。

2026/05/24 #Cursor #extensions

常见问题解决库

Cursor MCP server 连不上或看不到工具

在 Cursor 里加了 MCP server，却一直 disconnected，或聊天里看不到工具。九成是 PATH 不对、JSON 写错、或日志漏到了 stdout。五分钟内定位修好。

2026/05/24 #Cursor #mcp

常见问题解决库

Cursor 没识别到 Python venv（解释器选错）—— 完整修复指南

Cursor 选用系统 Python 而非项目 venv，导致 import 红线、lint 报错、agent 给出错误改动。修好解释器选择、venv 发现、shell PATH 与新版 Python Environments 面板。

2026/05/24 #Cursor #排查