症状：Roo Code 的确认提示不断打断你，开启“全部自动审批”又担心误删、泄密或越权。
最快解法：不要一次性全开，先在隔离环境中按读取、编辑、命令、浏览器和 MCP 工具逐级放行，只允许作用域明确、失败可恢复的动作。
谁适合看这份验收清单
如果你只是偶尔让 Roo Code 解释代码、生成补丁或查看测试结果，保留人工确认通常更稳妥。
这篇内容适合频繁使用 Roo Code 的个人开发者、准备把它部署到远程开发机或云端 Mac 的团队，以及需要审核 Agent 权限、密钥和 MCP 工具边界的安全与平台工程人员。
启用前先划定自动审批的红线
Roo Code 的自动审批不是一个简单的效率开关。官方文档将读取、编辑、终端命令、浏览器、MCP、模式切换、子任务和后续问题等动作分开控制；选中的动作会绕过确认提示，因此权限必须按类别审核，而不能用一个全局选项替代判断。官方自动审批说明
启用前先把权限分成五层：
- ✅ 只读操作：读取工作区文件、目录和代码搜索结果，通常是第一阶段候选。
- ⚠️ 受限编辑：只允许当前仓库内的代码修改，并保留 Git 变更记录。
- ⚠️ 终端命令：只允许可预测、幂等、失败后容易恢复的构建和测试命令。
- ❌ 浏览器与外部网络：涉及登录态、上传、表单提交或第三方数据时，默认人工确认。
- ❌ MCP 工具：逐个检查工具能力，不能因为服务器可信，就推断其所有工具都低风险。
密钥文件、系统目录、SSH 配置、发布凭据、生产环境、删除操作和部署动作，应默认保留人工确认。沙箱、容器或远程开发机只能缩小影响范围，不能消除提示注入、恶意脚本、错误参数和凭据滥用的风险。
⚠️ 经验提醒：自动批准写文件、修改 MCP 配置和执行终端命令叠加后，风险并不是简单相加。历史安全公告已经显示，相关权限组合可能造成远程代码执行，因此不要把旧版本的安全经验直接套到当前界面；发布前应重新核对版本和权限行为。官方安全公告
第一轮只放开读取和受限编辑
第一轮的目标不是让 Roo Code 连续跑完整任务，而是确认它到底能看见和改动什么。
先复制一个测试仓库，切换到测试分支，并准备一组不含真实密钥的样例文件。自动审批设置中只打开工作区内的读取权限；如果确实需要编辑，再单独打开工作区内写入，不要同时启用工作区外文件和受保护文件修改。
按下面顺序验收：
- 让 Roo Code 列出工作区目录，确认它没有读到用户目录、其他仓库或密钥目录。
- 在仓库中放置一个指向工作区外的符号链接，要求它读取链接目标，观察是否越过边界。
- 让它修改一个测试文件，检查变更是否只发生在指定目录。
- 使用
git diff检查修改范围，再用git restore验证是否能够恢复。 - 尝试让它修改
.roo/配置、环境文件或工作区外路径，确认系统仍会要求确认或直接拒绝。 - 保存权限设置截图、变更 diff 和越界操作记录。
通过条件是：读取范围清晰、编辑范围可解释、Git 可以恢复、拒绝记录完整。只要出现无法解释的目录访问、链接越界或恢复失败，就停止扩大权限。
官方权限说明指出，工作区外读取和写入需要额外开关；启用工作区外读取后，Roo Code 可能读取当前账户有权限访问的系统文件。这个选项不应作为“方便调试”的默认配置。官方权限边界说明
第二轮把终端审批拆成命令级测试
终端自动审批最容易被误判。命令是否安全，不仅取决于命令名称，还取决于参数、当前目录、环境变量、脚本内容、管道和重定向。
先分别测试四类命令：
- 构建命令：确认只生成工作区内的构建产物。
- 单元测试：确认失败时不会继续触发发布或清理。
- 依赖安装：确认包管理器使用预期锁文件和来源。
- 清理脚本：确认删除范围仅限缓存或构建目录，不触及源码与用户数据。
允许列表应尽量具体。例如，把 python 缩小为 python -m pytest，把包管理器缩小为项目明确使用的测试脚本，而不是允许所有相关命令。官方文档支持允许命令和拒绝命令并用，并说明更具体的拒绝项可以覆盖允许项；生产环境还应避免使用 * 放行全部命令。官方命令审批配置
验收时，还要准备故意扩大作用范围的测试：
- 在允许的测试命令后追加删除参数。
- 让命令通过管道执行远程脚本。
- 让脚本访问工作区外目录。
- 让命令读取环境变量中的密钥。
- 让构建命令继续执行发布或上传动作。
通过条件是：安全命令可以自动运行，参数扩大作用范围时重新要求确认或被拒绝。发布、删除、修改权限、读取凭据、上传制品和操作生产环境的命令，不应与普通测试命令共享同一条允许规则。
用这张表决定每一层是否放行
| 动作类别 | 首轮建议 | 可放行的前提 | 必须停止或人工确认的情况 |
|---|---|---|---|
| 工作区内读取 | ✅ 可先放开 | 目录范围明确，无法读取真实密钥 | 访问工作区外路径、符号链接越界 |
| 工作区内编辑 | ⚠️ 小范围放开 | 测试分支、Git 可恢复、变更可审计 | 修改配置、密钥、保护文件或仓库外文件 |
| 构建与单元测试 | ⚠️ 命令级放开 | 命令前缀明确、幂等、失败可重试 | 带删除、上传、发布、提权或远程脚本 |
| 依赖安装 | ⚠️ 临时放开 | 锁文件和来源固定，网络出口受控 | 修改包源、执行安装脚本、读取凭据 |
| 浏览器操作 | ❌ 默认手动 | 无登录态、无上传、无敏感表单 | 登录、支付、上传、提交外部变更 |
| MCP 只读工具 | ⚠️ 逐工具放开 | 输入范围明确，无外部副作用 | 读取敏感资源或返回凭据 |
| MCP 写入与外部动作 | ❌ 默认手动 | 有独立测试账号、日志和撤销方案 | 发消息、改数据、部署、删除或调用生产 API |
评分时不要只看“任务完成”。建议分别评估权限边界、越权拦截、回滚与日志三项；任意一项为 0 分，就不要进入下一阶段。任务完成得很快，不能抵消越权没有被拦截的事实。
MCP 工具采用双层允许列表
Roo Code 的 MCP 自动审批需要同时满足全局设置和单个工具的允许设置：先启用全局 MCP 自动批准，再在 MCP 服务器视图中为具体工具逐个勾选允许。两层授权不能混为一谈；一次测试中可用，也不代表服务器新增工具后仍然安全。
接入每个 MCP 服务器时，至少记录以下信息：
- 工具名称和服务器来源。
- 输入参数允许的路径、项目、账号或资源范围。
- 凭据来自环境变量、配置文件还是交互输入。
- 工具是读取数据、写入数据，还是触发外部动作。
- 调用日志保存在哪里。
- 如何撤销单个工具权限和整个服务器配置。
MCP 的“只读”标签也要谨慎理解。一个查询工具可能读取内部工单、代码仓库或云资源；一个写入工具可能修改数据库、创建云资源或触发部署。你需要审查工具实际调用的 API，而不是只看工具描述中的几个字。
官方工具说明把文件读取、文件编辑、命令执行和 MCP 交互分为不同工具组；自定义模式可以通过工具组控制能力范围，但模式限制不能替代对 MCP 服务器和工具本身的审查。官方工具系统说明
常见疑问集中在持续运行场景
哪些动作适合先交给自动审批
工作区内读取通常适合作为第一步；可通过 Git 恢复的局部编辑，可以在测试分支中短期放开。终端、浏览器和 MCP 需要更细的条件，密钥读取、系统目录、发布部署和破坏性命令则应继续人工确认。
终端命令的主要风险来自哪里
风险集中在命令参数和上下文，而不是单个命令看起来是否常见。当前目录、环境变量、脚本内容和网络出口都可能扩大影响范围，所以持续任务必须使用命令级允许列表，并对删除、发布、提权和远程脚本保留人工确认。
MCP 权限应怎样逐项核验
先确认全局 MCP 自动审批开关，再逐个工具设置允许；不能只打开全局开关就认为配置完成。对每个工具记录输入范围、凭据来源、外部副作用和撤销方法，资源访问还要单独验证是否受到全局设置控制。
持续运行的 Agent 是否要放进隔离环境
需要。持续运行的 Roo Code 应放在独立仓库、低权限账户和可销毁的远程开发环境中；如果任务依赖 Xcode 或 macOS 工具链，还要单独验证远程 Mac 的钥匙串、代码签名、网络出口和物理资源权限，不能直接套用普通容器结论。
远程试运行要验证隔离和回滚
本地测试通过后，不要直接把同一套设置复制到远程开发环境。远程开发环境通常同时拥有仓库凭据、网络出口、构建工具链和缓存数据，权限叠加后的后果可能比本地更难判断。
安排两类任务：
- 可回滚任务：让 Roo Code 修改测试分支中的少量文件、运行构建和测试，然后执行 Git 回滚。
- 故意越权任务：让它访问工作区外路径、读取模拟密钥、执行拒绝命令或调用未授权 MCP 工具。
重点检查以下证据：
- 仓库权限是否只覆盖测试项目。
- 网络出口是否限制到必要服务。
- 环境变量中是否没有生产凭据。
- 日志是否记录命令、参数、工具名、结果和时间。
- 超时后任务是否真的终止。
- 回滚是否恢复文件、生成物和配置。
- 越权请求是否被拦截，而不是只在日志中留下警告。
如果你通过 VNC 连接指南 管理远程 Mac，验收时还应检查远程桌面账户是否与 Agent 运行账户分离。需要 macOS 工具链的任务，可以参考 Mac mini 租赁方案 了解远程 Mac 的使用边界；远程环境的便利性不能替代权限隔离。
Roo Code 还提供自动批准请求数量限制，用于在连续调用达到阈值后暂停并要求重新确认。这类限制适合长任务的额外护栏，但不能代替命令、文件和 MCP 的逐项允许列表。官方请求限制说明
上线后按变更事件重新验收
自动审批不是一次配置、永久有效。以下事件发生后，应重新执行至少一轮低风险测试和一轮越权测试：
- Roo Code 升级或更换安装方式。
- MCP 服务器版本、启动命令或配置文件变化。
- 仓库脚本、构建流程或依赖源变化。
- 新增环境变量、云凭据或 SSH 密钥。
- 远程 Mac 更换系统、工具链或运行账户。
- Agent 任务从交互式执行改为无人值守执行。
保留权限的条件是：作用域仍然明确、日志完整、越权能够拦截、Git 或其他机制可以恢复。缩小权限的条件是：任务虽然完成，但出现不必要的目录访问、命令范围扩大、MCP 输入不透明或日志缺少关键参数。
撤销权限的条件是：出现无法解释的外部访问、凭据暴露、回滚失败、越权未拦截，或服务器行为与首次验收不一致。你可以定期抽查命令日志和异常 diff，而不是只依赖 Roo Code 的成功提示；账户、远程访问和使用边界可先通过 SSHMac 帮助中心核对，再决定是否扩展权限。
如果你当前使用的是普通本地开发机，直接开启全部自动审批的缺点很具体：工作区外文件可能被暴露，终端命令可能复用本机凭据，浏览器可能带着登录态执行外部操作；无人值守时，错误还可能持续累积到你发现为止。对于只需要临时算力、远程 Mac 工具链或隔离测试环境的任务，使用 SSHMac 的 Mac 环境通常更容易把仓库、账户、网络和生命周期单独管理。更稳妥的做法，是先在隔离环境完成一轮低风险任务，确认日志、越权拦截和回滚全部通过后，再扩大 Roo Code 自动审批范围。