AI 改动数据之前，MCP 客户端如何征求确认：2026 年对比
2026 年所有值得一提的 MCP 客户端，在助手运行会改动内容的工具之前都会先询问。答案的这一部分平淡无奇，但让人放心。有用的部分在于第一次询问之后会发生什么，因为没有人能长期每天点四十次“Allow”：每个客户端都提供了不再被询问的办法，而各家在这个办法能收得多窄上差别很大。
简而言之：Claude Code、Zed、Cursor 和 Devin Desktop 允许您按名称预先批准单个 MCP 工具。Codex，也就是 ChatGPT 桌面应用背后的引擎，则可以改为依据服务器自己的标签来决定——凡是未标记为只读的都要询问。 VS Code 在对话框层面两者兼顾，并增加了覆盖整个工作区的开关。这些设计没有哪个是错的，但它们出错的方式各不相同，而您该关心哪种出错，取决于服务器是谁写的。
本文与我们对哪些 MCP 客户端能运行本地服务器的梳理是姊妹篇。那一篇回答“能不能启动”，这一篇回答“当助手决定改动某些东西时，它会做什么”。下文所有内容均已于 2026 年 9 月 29 日对照各厂商的文档核实。
简短的答案
| 客户端 | MCP 工具的默认行为 | 最细的长期授权 | 是否依据注解决定？ |
|---|---|---|---|
| Claude Code | 询问（Manual 模式） | 按工具：在 allow、ask 或 deny 中写 mcp__server__tool |
文档未提及 |
| Claude Desktop 连接器 | 询问 | 按工具或类别：Always allow、Needs approval、Blocked | 把工具分为只读和写入/删除两类 |
| Codex CLI、IDE、ChatGPT 桌面应用 | 取决于模式 | 按服务器，可按工具覆盖 | 是：writes 模式、destructive 提示 |
| 网页版 ChatGPT（开发者模式） | 写操作会询问 | 按工具，仅限一次对话 | 是：readOnlyHint |
| Cursor | 询问 | server:tool 白名单 |
文档未提及 |
| VS Code | 询问（Manual permissions） | 按工具或服务器；会话、工作区或始终 | 文档未提及 |
| Zed | 询问（confirm） |
mcp:server:tool 规则 |
文档未提及 |
| Devin Desktop | 任何 MCP 工具前都询问 | 按工具或整个服务器；会话或永久 | 文档未提及 |
大部分含义落在两列上。“最细的长期授权”告诉您，能否只信任 search 而不信任 share。“是否依据注解决定”告诉您，客户端是否替您做这种区分——依据的是服务器给自己写的标签。
Codex 与 ChatGPT 桌面应用：四种模式加一个标签
Codex 的设计最为明确，而且由于 ChatGPT 桌面应用、Codex CLI 和 IDE 扩展共用一个配置文件，它同时覆盖这三者。每个 MCP 服务器都有一个 default_tools_approval_mode，任何工具都可以用 tools.<tool>.approval_mode 覆盖它。文档列出的取值是 auto、prompt、writes 和 approve。
值得细看的是 writes。用 OpenAI 的话说，它会“对未标记为只读的工具发起询问”。搜索静默运行，其他一切都会停下来询问，而完全没有注解的工具算作写操作——当服务器什么都没说时，这是安全的默认值。在这些模式之上，Codex 的批准文档还规定：如果工具声明了 destructive 注解，那么对它的 MCP 调用一律需要批准，除非它同时声明了读取注解。
如果您用的是旧配置，有一处变化值得了解：Codex 已不再支持 approval_policy = "untrusted"，这个已废弃的设置可能导致客户端无法启动。现在项目的信任改由该项目的 trust_level 设置。
网页版 ChatGPT 遵循同样的原则。在 Pro、Plus、Business、Enterprise 和 Education 账户可用的开发者模式中，“写操作默认需要确认”；ChatGPT 遵循 readOnlyHint，并把任何没有它的工具视为写操作。选择可以按工具记住，但只在本次对话的剩余时间内有效，不会更久。
Claude Code 与 Claude Desktop：按名称写规则
Claude Code 不读取注解来做决定。它使用三个列表中的权限规则——allow、ask 和 deny——并按固定顺序评估：先 deny，再 ask，最后 allow。MCP 工具的名称是 mcp__<server>__<tool>，所以 mcp__notes__search 放行一个工具，mcp__notes__get_* 放行一组工具，mcp__notes 或 mcp__notes__* 覆盖整个服务器。默认模式现在标为 Manual；更宽松的模式包括 acceptEdits、由分类器代替您审查操作的 auto，以及 bypassPermissions。
有两个细节偏向安全。来自项目中已提交的 .mcp.json 的服务器，在连接之前就需要您批准。此外，服务器作者可以给工具加上 _meta["anthropic/requiresUserInteraction"]，此后 Claude Code 每次调用都会弹出询问——即使在 acceptEdits、auto 和 bypassPermissions 下也是如此。
Claude Desktop 的连接器设置位于 Customize → Connectors，会把服务器的工具分为只读、写入/删除等类别，每个类别或单个工具都可以设为 Always allow、Needs approval 或 Blocked。
Cursor、VS Code、Zed 和 Devin Desktop：编辑器
Cursor 说得很直白：“Cursor 默认在使用 MCP 工具前征求批准。”MCP 遵循与终端命令相同的 Run Modes。在 Auto-review 中，白名单内的调用立即运行，其余一切交给分类模型处理；Run Everything 则不经询问运行所有工具调用。白名单接受带通配符的 server:tool 条目。有一个陷阱：服务器的工具白名单留空，就等于放行该服务器的所有工具。
VS Code 把默认级别称为 Manual permissions：凡未自动批准的都需要确认。对话框允许您只批准一次使用，或者对本次会话、整个工作区或今后所有调用授予批准，并且可以为每个 MCP 服务器设置按工具的批准。Allow all 会彻底取消询问，而由模型判断每次调用的 Assisted permissions 标为实验性功能。有一个例外值得注意：随代理插件一起提供的 MCP 服务器“在您安装插件时即被隐式信任”，会跳过单独的启动信任询问。安装插件本身就是信任决定。
Zed 的规则体系最易读。agent.tool_permissions.default 在您不改动时为 confirm，可选值还有 allow 和 deny。规则把 MCP 工具写作 mcp:<server>:<tool_name>，可以设为始终允许、始终确认或始终拒绝，拒绝优先。询问框本身提供“Allow once”“Deny once”以及针对该工具的“Always for”；对 MCP 工具来说，只有工具级别的选项。
Devin Desktop，也就是原来的 Windsurf，在改名的同时也换了模型。它的代理 Devin Local“用更细粒度的权限系统取代了自动执行级别”，默认在调用任何 MCP 工具前都会询问。在询问框中，您可以放行一个工具或该服务器上的所有工具，时效为本次会话或永久，而 Deny 规则的优先级高于一切。Enterprise 管理员可以为整个组织预先批准特定的服务器或工具。
注解能做什么，不能做什么
MCP 规范为服务器提供了一套描述自身工具的词汇：readOnlyHint、destructiveHint、idempotentHint、openWorldHint。它同时也告诉客户端该在多大程度上相信这些注解：客户端“必须将工具注解视为不可信，除非它们来自受信任的服务器”。它还要求有人参与其中，并能拒绝任何工具调用。
这样一来，上面两种设计的定位就清楚了。像 Codex 的 writes 模式那样依据注解做决定的客户端，配合您信任的服务器很方便：只需配置一行，服务器新增的每个写入类工具都会被自动纳入询问。换成您不信任的服务器，它的安全程度就完全取决于服务器是否诚实。一个会改动数据却自称只读的工具，会在不经询问的情况下运行。
像 Claude Code 或 Zed 那样要求写出工具名的客户端，出错的方向正好相反。它不在乎服务器声称什么，但更新中新增的写入类工具，只有在您的规则足够宽、能把它涵盖进去时才会被覆盖——或者规则足够窄、漏掉了它，于是退回到询问。基于名称的规则最安全的写法是“放行这些读取操作”，而不是“放行这个服务器”。
适用于可读可写服务器的合理配置
无论用哪个客户端，以下四个习惯都能覆盖大部分风险：
- 按名称放行读取操作，而不是放行整个服务器。 搜索和阅读转写稿是助手整天都在做的事；在这里询问代价最高、保护作用最小。
- 对任何共享或替换内容的操作保留询问。 发布给他人和覆盖文本，是两类无法靠把某个值改回去来撤销的改动。
- 只对信任的服务器依赖注解。 对于来自您从未用过的注册中心的服务器，改为在规则中写明其工具名。
- 给信任度较低的客户端一个只读实例。 如果服务器支持只读模式，就可以让一个客户端只能读取，而另一个客户端保留完整权限。
危险信号：Cursor 白名单中某个服务器的工具列表为空、团队里没人审查过的 VS Code 插件，以及对一个连名字都没看过的工具点了“Always allow”。
在 Speak-Y 中是什么样子
Speak-Y MCP 服务器为这两类客户端都做了设计。读取类工具——搜索录音，阅读转写稿、摘要和待办事项，列出标签和频道——带有 readOnlyHint，直接从您的机器上读取资料库。会改动内容的工具——标签、标题、说话人名称、重新转写、共享到团队频道——被声明为改动数据的工具，并经由正在运行的 Speak-Y 应用执行，每次调用都会被记录，也可以将其关闭。
其中两个特意标记了 destructiveHint：retranscribe，因为它会替换录音当前的文本，包括手动所做的修正；share_to_channel，因为在您撤回之前，同事可能已经读到了录音。在 Codex 的 writes 模式下，这些询问无需任何配置就会出现；在 Claude Code 或 Zed 中，按名称放行读取类工具，其余保持为 ask 即可。
如果您希望某个客户端只能读取，就在该客户端的配置中以 --read-only 启动服务器：改动类工具根本不会发布给它，也就不存在误批准的可能。从设置 → 集成一键即可完成安装，MCP 服务器在包括 Free 在内的所有套餐上都免费。
批准询问只是让可写入的助手安全可用的控制手段之一。其余的——哪些改动可以撤销、日志会保留什么——在什么让 MCP 写入权限变得安全一文中有介绍，而 MCP 文档提供了各客户端的配置说明。
FAQ
运行会改动数据的工具之前，MCP 客户端会先询问吗？
所有主流客户端默认都会询问。Claude Code、Cursor、VS Code、Zed 和 Devin Desktop 在您预先批准之前，每次运行 MCP 工具都会先询问；ChatGPT 的开发者模式则对每个未标记为只读的工具都要求确认。区别在于之后能把预先批准限定到多细：按工具、按服务器、按会话，还是永久。核实于 2026 年 9 月 29 日。
哪些 MCP 客户端依据 readOnlyHint 注解决定何时询问？
Codex 和 ChatGPT 明确这样做。Codex 的 writes 批准模式会对未标记为只读的工具发起询问，并且在调用自称 destructive 的工具之前一律询问；ChatGPT 开发者模式把任何没有 readOnlyHint 的工具都视为写操作。Claude Code、Cursor、VS Code 和 Zed 的文档没有把注解列为批准的依据，规则需要您自己按工具名来写。
能否自动批准读取类工具，同时在写入前仍然询问？
可以，本次对比中的所有客户端都能做到，只是机制不同。在 Claude Code、Zed、Cursor 和 Devin Desktop 中，您按名称放行读取类工具，例如 Claude Code 里的 mcp__server__search 或 Zed 里的 mcp:server:search。在 Codex 中，writes 模式一行配置即可，但前提是服务器如实标记了自己的读取类工具。
readOnlyHint 这类工具注解算是安全保证吗？
不算。MCP 规范要求，除非注解来自受信任的服务器，否则客户端必须把工具注解视为不可信。一个把写入类工具标成只读的服务器，会让所有基于该提示的客户端策略失效。请把注解当作对已信任服务器的一种便利，对不信任的服务器，则在规则中明确写出工具名。
把会议记录服务器连接到 AI 助手，最安全的做法是什么？
只预先批准读取类工具，对一切改动数据的操作保留询问，并给信任度较低的客户端一个只读实例。使用 Speak-Y 时，在某个客户端的配置中以 --read-only 启动服务器，改动类工具就会从该客户端完全消失，而另一个客户端仍可凭各自的询问保留完整权限。