Claude Code 权限设置完整指南：6 种模式与安全沙箱新手入门
30 秒快速了解
Claude Code 具备读取、编辑文件、执行命令和网络访问能力，因此权限控制并非繁琐弹窗，而是确保 AI 安全操作的关键。新手只需记住三个要点：日常使用 default 模式（只读操作无需确认，修改内容需先获许可；diff 即代码变更前后差异），规划重大改动时切换 plan 模式（仅执行只读探索，先输出计划再行动），bypassPermissions 模式切勿触碰（跳过所有检查，仅适用于隔离容器环境）。
根据自身角色选择合适策略：
| 用户类型 | 推荐方案 |
|---|---|
| 完全新手 / 首次安装 Claude Code | 使用 default 模式，先执行只读分析，理解 diff 后逐步放开权限 |
| 日常编码开发者 | 以 default 为基础，机械任务临时切换 acceptEdits，高频安全命令写入 allowlist |
| 架构调整 / 大型重构 / 接手陌生代码库 | 先进入 plan 模式进行只读规划，明确影响范围后再批准执行 |
| 团队 / CI / 自动化负责人 | 通过项目级 settings.json 统一规则，结合托管策略与沙箱，使用 dontAsk 运行无人值守任务 |
新手常见误区：为省事而直接使用 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 能否执行特定类别的动作：读取文件、写入文件、运行命令、访问网络、调用工具、触发外部服务。各类动作风险不同，不能一概而论。
根据官方分层逻辑，工具大致分为三档：
| 工具类型 | 示例 | 默认是否需批准 |
|---|---|---|
| 只读类 | 读取文件、Grep 搜索 | 无需确认，直接执行 |
| Bash 命令 | 执行 shell 命令 | 需确认，确认后可“按项目+命令”长期记忆 |
| 文件修改 | Edit / Write 修改文件 | 需确认，确认后保留至会话结束 |
理解权限时，不应只关注“允许 / 拒绝”的二元开关。真正需要评估的是三方面：该动作的目的、影响范围、是否可回滚。读取通常风险较低，但涉及密钥、客户数据、内部配置时需谨慎；运行命令的风险取决于具体内容，查询状态、运行测试通常可控，删除文件、发布部署则须严格把关。
三、6 种权限模式，一表清晰对比
Claude Code 提供 6 种权限模式（许多旧教程仅提及 3 种加一个 bypass，已过时）。每种模式的核心区别在于“哪些动作无需询问即可执行”：
| 模式 | 无需询问即可执行的动作 | 适用场景 |
|---|---|---|
default（默认） | 只读操作 | 新手入门、敏感工作 |
acceptEdits（接受编辑） | 只读 + 工作目录内文件编辑 + 常见文件命令（mkdir / touch / rm / rmdir / mv / cp / sed） | 边写边审的迭代开发 |
plan（计划） | 只读操作 | 改动前先熟悉代码库 |
auto（自动） | 几乎全部，附带后台安全审查 | 长任务、减少弹窗干扰 |
dontAsk | 仅放行预先批准的工具 | 锁定的 CI 和脚本环境 |
bypassPermissions（绕过） | 所有动作 | 仅隔离容器和虚拟机 |
需注意，除 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(具体内容)。以下是各类工具的示例，均来自官方文档：
| 规则 | 含义 |
|---|---|
Bash(npm run build) | 精确匹配命令 npm run build |
Bash(npm run *) | 匹配以 npm run 开头的命令（* 为通配符） |
Read(./.env) | 匹配读取当前目录下的 .env 文件 |
Edit(/src/**/*.ts) | 匹配编辑项目内 src/ 目录下的 .ts 文件 |
WebFetch(domain:example.com) | 匹配抓取 example.com 的网络请求 |
mcp__puppeteer__na vigate | 匹配 puppeteer 服务器的 na vigate 工具 |
一个新手友好的日常配置示例如下：
{"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 个位置，优先级从高到低排列如下：
| 优先级 | 配置位置 | 用途 |
|---|---|---|
| 1（最高） | 托管设置（managed，企业策略） | 组织红线，任何下层无法修改 |
| 2 | 命令行参数 | 临时会话覆盖 |
| 3 | .claude/settings.local.json | 本地项目，不纳入 Git |
| 4 | .claude/settings.json | 项目级，提交 Git、团队共享 |
| 5（最低） | ~/.claude/settings.json | 用户级，跨所有项目 |
需牢记一条铁律：任何一层 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
