Claude Code权限新手指南：六种模式与安全沙箱使用

Claude Code 权限设置完整指南：6 种模式与安全沙箱新手入门

30 秒快速了解

Claude Code 具备读取、编辑文件、执行命令和网络访问能力，因此权限控制并非繁琐弹窗，而是确保 AI 安全操作的关键。新手只需记住三个要点：日常使用 default 模式（只读操作无需确认，修改内容需先获许可；diff 即代码变更前后差异），规划重大改动时切换 plan 模式（仅执行只读探索，先输出计划再行动），bypassPermissions 模式切勿触碰（跳过所有检查，仅适用于隔离容器环境）。

根据自身角色选择合适策略：

新手常见误区：为省事而直接使用 bypassPermissions 或 --dangerously-skip-permissions，导致 AI 在未充分知情的情况下修改了不应变更的内容。对于实际项目，切勿将“减少询问”误解为“无需把关”。

要点速览

• Claude Code 提供 6 种权限模式：default / acceptEdits / plan / auto / dontAsk / bypassPermissions。
• 通过命令行按 Shift+Tab 键可在 default → acceptEdits → plan 三种模式间循环，其余模式需附带参数启用。
• 精细控制依赖 settings.json 中的 allowlist（allow）/ denylist（deny），评估顺序为 deny → ask → allow。
• 配置分为 5 层，优先级由高到低：托管 > 命令行 > 本地 > 项目 > 用户，任一层设置 deny 后下层无法修改。
• 安全沙箱（sandbox）并非权限模式，它在命令执行后通过操作系统边界管理文件与网络访问。

一、为何新手需重视权限设置

权限的本质，是为 AI 的真实操作能力安装一道安全刹车。Claude Code 与仅提供建议的聊天工具不同：它编辑文件，文件即刻变更；它执行命令，命令真实运行。能力越大，越需要一套机制，确保关键操作前你仍能保持控制。

新手阶段风险更高，原因在于：你可能尚未熟悉项目结构，也难以一眼判断某些命令的潜在影响。此时过度开放权限，容易让 AI 误改关键文件，或执行意料之外的命令。

这也是 Claude Code 能够应用于实际代码库的信心所在：权限被设计为可分层、可配置、可审计，重要操作发生前用户始终能叫停。模型能力固然重要，但具备“随时可踩刹车”的边界机制，才决定了能否放心地将其用于核心项目。

保守不等于不用。你可以先让 AI 进行只读分析、制定计划并说明所需权限，确认后再允许其修改指定文件。这样既能推进任务，又保留了判断权。合理的用法并非一味拒绝或完全允许，而是根据风险等级采取不同处理方式。

二、Claude Code 权限覆盖哪些内容

权限控制决定 Claude Code 能否执行特定类别的动作：读取文件、写入文件、运行命令、访问网络、调用工具、触发外部服务。各类动作风险不同，不能一概而论。

根据官方分层逻辑，工具大致分为三档：

理解权限时，不应只关注“允许 / 拒绝”的二元开关。真正需要评估的是三方面：该动作的目的、影响范围、是否可回滚。读取通常风险较低，但涉及密钥、客户数据、内部配置时需谨慎；运行命令的风险取决于具体内容，查询状态、运行测试通常可控，删除文件、发布部署则须严格把关。

三、6 种权限模式，一表清晰对比

Claude Code 提供 6 种权限模式（许多旧教程仅提及 3 种加一个 bypass，已过时）。每种模式的核心区别在于“哪些动作无需询问即可执行”：

需注意，除 bypassPermissions 模式外，其余 5 种模式永远无法自动批准写入“受保护路径”——例如 .git、.claude、.vscode、.idea 等目录，以及 .bashrc、.zshrc、.gitconfig 等文件。这些内容过于敏感，任何宽松模式下修改均需用户确认。这是 Claude Code 防止“AI 破坏仓库状态或自身配置”的底线设计。

以下五节将详细解析实践中常用的几种模式。

四、default 与 plan：新手最应掌握的模式

这两种模式可覆盖新手 90% 的使用场景，建议先深入理解。

default（默认）模式为出厂设置：只读操作直接执行，修改文件或运行非只读命令时会首次询问，你可选择“本次允许”或“未来同类操作均允许”。其优势在于平衡——既不会因每次读取而中断你，又将所有写入和命令置于监控之下。新手从此模式入手最为稳妥。

plan（计划）模式为“只读 + 先规划”：Claude 可读取文件、执行只读命令进行探索，并生成修改计划，但不会触碰源文件。计划完成后会暂停等待决策——批准并执行、继续完善计划、或手动逐项审核改动。

何时切换至 plan 模式：

• 架构级改动（重构、迁移）——先把握全局再行动
• 首次接触陌生代码库——让 AI 先分析结构
• 影响范围不明确的改动——不确定涉及多少文件
• 不确定 AI 是否理解需求时——通过计划反向验证其理解

五、acceptEdits：提速但勿滥用

acceptEdits（接受编辑）模式下，Claude 在工作目录内创建和编辑文件时不再逐项弹窗，状态栏会显示“accept edits on”。除文件编辑外，官方文档明确其会自动放行七种常见文件命令：mkdir、touch、rm、rmdir、mv、cp、sed（命令前附带 timeout、nice 等无害包装时同样放行）。

其自动放行仅覆盖当前工作目录和显式添加的目录（additionalDirectories），且有明确边界，并非完全放开：

• 工作目录外的路径——仍需询问
• 写入受保护路径（.git、.claude 等）——仍需询问
• 除上述七种之外的其他 bash 命令——仍需询问

危险性中等：修改文件无需逐一确认，但 Git 仍可审核并提供回滚机会。适用于机械重复任务（如批量生成测试模板，频繁确认影响效率），且已有干净的 Git 检查点；不适合重要代码改动、不熟悉的项目、或无 Git 提交检查点的情况。

六、auto 与 dontAsk：进阶新增模式

这两种模式于 2026 年引入，新手可能暂时用不上，但需了解其存在，避免与前述模式混淆。

auto（自动）模式下，Claude 不会弹窗执行，但有一个独立的分类器模型在每次动作前进行审查，自动拦截三类危险行为：超出当前请求范围的、指向陌生基础设施的、疑似受恶意内容操控的。默认放行“工作目录内的本地文件操作、按依赖清单安装包、只读网络请求”，默认拦截“curl | bash 下载执行、向外部端点发送敏感数据、生产部署和迁移、强制推送或直接推 main”等动作。

auto 模式有明确使用门槛，任何一条不满足均无法启用（以官方最新文档为准）：

• 版本：Claude Code v2.1.83 及以上。
• 模型：Claude Opus 4.6 及以上，或 Sonnet 4.6；旧版型号（含 Sonnet 4.5、Opus 4.5、Haiku）均不支持。
• 平台：仅限 Anthropic API，Bedrock、Vertex、Foundry 不可用。
• 团队：Team / Enterprise 账户需管理员在后台先开启。

若 Claude Code 提示 auto 不可用，多半是上述条件未满足，而非临时故障。它属于研究预览功能——能减少弹窗，但不保证绝对安全，仅适用于你信任大方向的任务，不能替代对敏感操作的人工复核。

dontAsk 模式则相反：仅放行预先批准的工具，其余一律自动拒绝（连本应弹窗的也直接拒），适用于 CI 流水线和锁定环境。它与 auto 均不在 Shift+Tab 默认循环中，需带启动参数启用。

七、bypassPermissions：风险最高，99% 用户不该使用

bypassPermissions（绕过权限）模式跳过所有权限提示和安全检查，工具调用立即执行——这是 Claude Code 中唯一可能导致严重后果的模式（命令行旧参数 --dangerously-skip-permissions 与其等价）。

真正适用的场景极少：隔离容器、一次性虚拟机、无网开发容器——即 Claude 再怎么操作也不会影响主机环境。切勿在生产代码、不熟悉的项目、或首次运行提示词时使用。

其硬性约束包括：

• 对提示词注入无防护——需要无弹窗且附带后台安全检查时，应使用 auto 模式而非此模式。
• 即使在此模式下，rm -rf /、rm -rf ~ 等删除根目录或家目录的命令仍会弹窗拦截，作为防模型失误的安全机制。
• 无法从普通会话直接切换至 bypassPermissions，必须通过 --permission-mode bypassPermissions（或旧参数 --dangerously-skip-permissions）重启。
• 在 Linux 和 macOS 上，以 root 或 sudo 身份运行此模式会被直接拒绝。
• 管理员可在托管设置中将 disableBypassPermissionsMode 设为 disable，从组织层面彻底禁用。

八、利用 allowlist 和 denylist 精细控制命令

模式设定“基调”，而真正的精细控制依赖规则。在 settings.json 的 permissions 字段中，有三个数组构成你的 allowlist（白名单）和 denylist（黑名单）：

• allow：白名单，匹配后自动放行、不弹窗
• ask：每次都需确认
• deny：黑名单，匹配后直接拦截

规则格式为 Tool 或 Tool(具体内容)。以下是各类工具的示例，均来自官方文档：

一个新手友好的日常配置示例如下：

{"permissions": {"defaultMode": "default","allow": ["Bash(npm run *)","Bash(git status *)","Bash(git log *)"],"deny": ["Bash(rm *)","Bash(git push *)"]}}

此规则含义：运行脚本、查看 Git 状态和日志自动放行，删除和推送操作一律拦截。

关键机制：三个数组的评估顺序固定为 deny → ask → allow，第一条匹配的规则生效。换言之，deny 永远优先——只要某动作匹配了 deny，即使 allow 中也有对应规则，仍会被拦截。

九、5 层配置文件，层级决定优先级

权限规则可写入 5 个位置，优先级从高到低排列如下：

需牢记一条铁律：任何一层 deny 的内容，下层无法通过 allow 恢复。例如，用户设置允许某权限，但项目设置 deny 了它，最终以 deny 为准。反之，用户级的 deny 也会覆盖项目级的 allow——因为无论哪一层，deny 均优先于所有 allow 评估。

十、安全沙箱（sandbox）：与权限模式功能不同

许多人将“沙箱”与“权限模式”混为一谈，官方文档已明确说明：/sandbox 并非权限模式，二者为互补的两层。

一句话区分：

• 权限模式决定“本次工具调用是否执行、是否需先询问”——由 Claude Code 在调用前判断。
• 安全沙箱决定“bash 命令运行后能访问哪些文件、连接哪些网络域名”——由操作系统强制实施。

沙箱的工作原理：它将 bash 命令及其子进程限制在 OS 级别的盒子内，默认仅可写入当前工作目录，读取权限较宽松但可收紧，网络方面默认不开放任何域名，首次连接新域名时才会询问。它依赖操作系统自带的安全机制——macOS 使用 Seatbelt，Linux 和 WSL2 使用 bubblewrap（原生 Windows 不支持，需在 WSL2 中运行）。通过 /sandbox 命令开启，可选择“自动放行”或“照常走权限提示”两种沙箱模式。

为何需两层叠加使用——这是纵深防御的核心：权限规则在 Claude“打算做”之前就进行拦截，沙箱则在命令实际运行时通过操作系统的硬边界提供兜底保护。即使一次提示词注入骗过了 Claude 的判断，让其执行了危险命令，沙箱的 OS 边界仍能阻止命令访问边界外的文件和网络。新手无需一开始就配置复杂规则，只需了解“沙箱与权限模式分工不同、能提供额外一层保护”即可。

十一、新手应避免的 5 个常见误区

第一个误区，为省事而完全放开权限。短期方便、长期风险高。正确做法是按风险分层授权，低风险操作写入 allowlist，高风险操作保留确认环节。

第二个误区，仅关注命令名称，忽视运行目录。同一命令在不同目录下影响差异巨大。查看权限请求时，需结合“当前所在目录、涉及哪些文件”综合判断。

第三个误区，允许 Claude 修改后未查看 diff。AI 的文字总结并非最终验收标准，diff 才是真实依据。acceptEdits 模式下尤其应养成事后查看 git diff 的习惯。

第四个误区，将发布、提交、删除视为普通写入。这些属于高风险操作，会影响真实用户、资产或外部系统，必须单独确认，不能图省事纳入自动放行。

第五个误区，将沙箱视为万能保险。沙箱能阻止越界访问，但存在自身边界：网络过滤不解密 TLS 流量，放宽至 github.com 等大域名仍可能被用于外泄数据。沙箱是“降低风险”而非“彻底隔离”，需配合权限规则共同使用才更可靠（TLS 指 https 等加密传输，沙箱仅查看域名，不解析加密内容）。

十二、新手练习路径建议

权限不是看懂就会，需要实际操作培养手感。按以下节奏进行：

第一天，只读分析。保持在 default 模式，让 Claude 阅读项目结构、解释文件、列出其认为存在风险的部分。你仅查看，不批准任何操作。

第二天，小范围写入。只让 AI 修改一个文件，修改后立即查看 git diff，确认其改动符合预期。

第三天，运行低风险验证。例如运行测试或格式检查，但先让 AI 用自然语言说明该命令的作用、涉及哪些读写、失败可能造成的影响。

一周后，执行带计划的中等任务。先进入 plan 模式生成计划，审核通过后再批准执行；高风险操作仍仅让 AI 准备命令，不直接运行。

两周后，固化规则。将每日重复批准的低风险命令写入 settings.json 的 allowlist，将每次令你犹豫的操作写入 deny。规则稳定后，弹窗数量将明显减少，但安全边界依然存在。

十三、结语：边界清晰，协作更可靠

权限的核心在于边界感。并非不信任 Claude Code，而是确保其在正确范围内发挥能力。边界清晰，AI 的执行才能产生实际价值。

若不确定某个操作是否应允许，可先让 AI 说明四件事：该操作的目的、影响范围、是否可回滚、是否存在只读替代方案。能清晰回答，再考虑放行。

最佳的权限设置，既不是永远弹窗，也不是永远自动，而是让低风险任务顺畅执行、高风险操作及时暂停。权限分层、规则固化、沙箱兜底，这三方面配置到位后，Claude Code 将更像一个可控的执行伙伴，而非随时可能越界的黑箱。

十四、进阶学习方向

权限需与自动检查、工具接入、任务说明、项目规则协同使用才能发挥最大价值。推荐继续学习以下内容：

• Claude Code Hooks 自动化指南——通过 PreToolUse 实现比 allowlist 更灵活的动态权限检查
• Claude Code MCP 工具指南——为 Claude 接入外部工具，权限规则中的 mcp__ 即用于管理此类工具
• Claude Code 提示词工程指南——清晰定义任务边界，便于权限判断
• Claude Code CLAUDE.md 配置指南——将“禁止自动发布”等规则写入项目记忆

外部参考（官方文档）：

• 权限模式：https://code.claude.com/docs/en/permission-modes
• 权限规则配置：https://code.claude.com/docs/en/permissions
• 安全沙箱：https://code.claude.com/docs/en/sandboxing