Claude Code 权限新手指南：6 种模式 + 安全沙箱怎么用

Claude Code 权限怎么设置？6 种模式 + 安全沙箱新手指南

预计阅读 18 分钟。读完你会知道 Claude Code 的 6 种权限模式分别管什么、Shift+Tab 怎么循环、allowlist 怎么配、5 层配置谁说了算，以及安全沙箱和权限模式到底差在哪——这样你才敢让 AI 真正进项目干活，又不怕它越界。

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 敢被放进真实代码库的底气所在：权限被做成可分层、可配置、可审计，重要操作发生前人始终能叫停。模型能力强不强是一回事，有没有这套「随时能踩刹车」的边界机制，决定了你敢不敢把它用在要紧的项目上。

保守不等于不用。你完全可以让它先只读分析、列出计划、说明需要哪些权限，你确认后再允许它改指定文件。既推进了任务，又保住了判断权。真正成熟的用法不是永远拒绝、也不是永远允许，而是按风险做不同处理。

二、Claude Code 权限到底管什么

权限管的是 Claude Code 能不能执行某一类动作：读取文件、写入文件、运行命令、访问网络、调用工具、触发外部服务。每类动作的风险不同，不能一刀切。

按官方的分层逻辑，工具大致分三档：

💡 通俗讲：默认状态下 Claude Code 是「只读实习生」——让它看、让它查、让它分析都不拦你；可一旦它要动手改文件或跑命令，就得先举手问你一声。权限模式和规则，就是你给这个实习生定的「哪些事可以自己做、哪些事必须先报告」的工作手册。

理解权限时，别只盯着「允许 / 拒绝」这个二元开关。真正要看的是三件事：这个动作的目的是什么、影响范围多大、能不能回滚。读取通常风险低，但读到密钥、客户资料、内部配置就要小心；运行命令的风险全看命令内容，查状态、跑测试通常可控，删文件、发布部署就得谨慎。

三、6 种权限模式，一张表看懂

Claude Code 一共有 6 种权限模式（很多旧教程只讲到 3 种 + 一个 bypass，已经过时了）。每种模式的核心区别，是「哪些动作不用问你就能跑」：

💡 通俗讲：把这 6 种模式想成「放权的 6 个档位」。default 是最稳的一档，几乎什么都先问你；bypassPermissions 是最猛的一档，什么都不问直接干。中间四档在「省心」和「可控」之间各占一个位置，按任务风险往上或往下调。

有一个贯穿所有模式的安全底线值得记住：除了 bypassPermissions，其余 5 种模式都永远不会自动批准写「受保护路径」——比如 .git、.claude、.vscode、.idea 这些目录，以及 .bashrc、.zshrc、.gitconfig 这些文件。它们太敏感，任何宽松模式下要动都得你点头。这是 Claude Code 防止「AI 改坏仓库状态或自己的配置」的兜底设计。

下面五节把日常会真正用到的几种模式拆开讲。

四、default 与 plan：新手最该吃透的两种模式

这两种模式覆盖了新手 90% 的场景，先把它们吃透。

default（默认）模式是出厂状态：只读动作直接跑，要改文件或跑非只读命令时第一次会问你，你可以选「这次允许」或「以后这类都允许」。它的好处是平衡——既不会每个读取都打断你，又把所有写入和命令卡在你眼皮底下。新手从这里开始，错不了。

plan（计划）模式是「只读 + 先规划」：Claude 能读文件、跑只读命令探索、写出一份修改计划，但不碰你的源文件。计划做好后它会停下来问你怎么办——批准并开始、继续打磨计划、还是手动逐个审改动。

什么时候切到 plan：

• 架构级改动（重构、迁移）——先看清全局再动手
• 第一次接触陌生代码库——让它先摸清结构
• 影响范围不确定的操作——不确定会牵动多少文件
• 不确定 AI 是否真懂需求时——用计划反过来验证它的理解

🔥 翔宇判断：plan 模式是被严重低估的一档。新手最容易犯的错，是上来就让 AI 直接改，改完发现方向不对再回滚，来回折腾。先用 plan 出一份计划，你花两分钟看它「打算怎么做」，比花二十分钟收拾「已经做错的」划算得多。越是大改，越要先 plan。

五、acceptEdits：提速但别滥用

acceptEdits（接受编辑）模式让 Claude 在工作目录内创建和编辑文件不再逐个弹窗，状态栏会显示「accept edits on」。除了文件编辑，按官方文档它还会自动放行一批常见文件命令，确切就是这七个：mkdir、touch、rm、rmdir、mv、cp、sed（命令前带上 timeout、nice 这类无害包装时同样放行）。

它的自动放行只覆盖当前工作目录和你显式加进来的目录（additionalDirectories），并且有明确边界，不是「全放开」：

• 工作目录之外的路径——仍然问你
• 写受保护路径（.git、.claude 等）——仍然问你
• 除上面那批之外的其他 bash 命令——仍然问你

危险性中等：改文件不用你点确认，但 git 还能审、还有回滚机会。适合的场景是机械重复任务（比如批量生成测试模板，每次都点确认太烦）且你已经有干净的 git 检查点；不适合重要代码改动、不熟悉的项目、或者没做 git 提交检查点的时候。

⚠️ 常见踩坑：有人把 acceptEdits 当成「全自动」，结果在没提交 git 的工作区里让它连改十几个文件，发现方向错了想回退，却发现改动和原来未提交的内容混在一起，理不清。正确做法是改之前先 git commit 一个干净检查点，再切 acceptEdits，做完一段切回 default 复盘。

六、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 默认循环里，要用得带启动参数。

💡 通俗讲：auto 像请了个会自己判断的助理，你不盯着它也会自动躲开危险动作，但它的判断不是 100% 保险；dontAsk 像一台只认白名单的自动售货机，单子上有的才给、没有的一概不给。两者都不是给新手日常练手用的，知道有这回事就行。

七、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，从组织层面彻底封掉它。

🔥 翔宇判断：99% 的用户永远不需要 bypassPermissions。当你觉得「非它不可」时，大概率是其他模式的规则没配好。它的代价是非对称的——顺的时候快那么一点点，错一次的损失可能是整个项目。把它留在隔离环境里，别带进真实工作。

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

模式定的是「基调」，真正精细的控制靠规则。在 settings.json 的 permissions 里有三个数组，构成你的 allowlist（白名单）和 denylist（黑名单）：

• allow：白名单（allowlist），匹配到就自动放行、不弹窗
• ask：每次都让你确认
• deny：黑名单（denylist），匹配到直接拦死

规则格式是 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 里也写了它，也照样被拦。

⚠️ 常见踩坑：很多人想用 Bash(curl http://github.com/ *) 这种规则把 curl 限制在某个域名，但这非常脆弱——换成 https、加个 -X GET 参数、用变量拼 URL、甚至多打个空格，规则就匹配不上了。官方建议：要管网络访问，就用 deny 拦掉 curl、wget，再用 WebFetch(domain:...) 放行可信域名；或者上 Hooks 的 PreToolUse 做动态校验。allowlist 速度最快，但要拦命令参数这种细活，Hooks 更靠谱。想了解 Hooks 怎么配，可以看 Claude Code Hooks 自动化指南。

九、5 层配置文件，谁说了算

权限规则可以写在 5 个地方，优先级从高到低排成一条链：

有一条铁律必须记牢：任何一层 deny 掉的东西，下层都无法再 allow 回来。比如用户设置允许某权限、但项目设置 deny 了它，最终以 deny 为准。反过来用户级的 deny 也会盖掉项目级的 allow——因为不管哪一层的 deny，都先于所有 allow 求值。

💡 通俗讲：记住「越靠上越权威、deny 永远赢」这两条，分层就不会乱。个人偏好放用户级（跨项目复用），团队规则放项目级（进 git 大家共享），临时实验放 local（不污染仓库），企业级红线放托管设置（谁都改不动）。层级想清楚，再多人协作也不会把权限配成一锅粥。

十、安全沙箱（sandbox）：跟权限模式不是一回事

很多人把「沙箱」和「权限模式」混为一谈，官方文档专门澄清过：/sandbox 不是权限模式，二者是互补的两层。

一句话分清：

• 权限模式管的是「这次工具调用要不要跑、要不要先问你」——Claude Code 在调用之前判断。
• 安全沙箱管的是「bash 命令跑起来之后能碰哪些文件、连哪些网络域名」——由操作系统强制。

沙箱的工作方式：它把 bash 命令及其子进程关进一个 OS 级的盒子里，默认只能写当前工作目录、读权限放得宽但可收紧，网络默认一个域名都不放、第一次连新域名才问你。它靠的是操作系统（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 读项目结构、解释文件、列出它觉得有风险的地方。你只看不批。

第二天，小范围写入。只让它改一个文件，改完立刻看 git diff，确认它改的和你想的一致。

第三天，运行低风险验证。比如跑测试或格式检查，但先让它用人话解释这条命令会做什么、读写什么、失败会怎样。

一周后，带计划的中等任务。先进 plan 模式出计划，你审过再批准执行；高风险动作仍然只让它准备命令、不让它直接跑。

两周后，固化你的规则。把每天重复批准的低风险命令写进 settings.json 的 allowlist，把每次都让你犹豫的动作写进 deny。规则一旦稳定，弹窗会明显减少，但边界还在。

⚠️ 常见踩坑：不少人跳过前几天，第一天就想让 AI 自己干一整个功能，结果要么被弹窗淹没、要么放太开出事故。渐进授权慢一点，但每一步都看得见结果、控得住范围，这比一次性把整段任务的权限全开稳得多。

十三、写在最后：边界清楚，协作才稳

权限的核心是边界感。你不是不信任 Claude Code，而是要让它在正确范围内发挥能力。边界清楚，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