权限与安全

这一课你将能做到

1. 读懂权限提示与三种模式（default / acceptEdits / plan）的适用场景，按任务风险选择放权程度
2. 在 settings.json 中编写 allow / ask / deny 规则，实现「安全命令免打扰、危险操作必拦截」
3. 说明三层配置文件（用户级 / 项目共享级 / 项目本地级）的优先级与团队协作分工

为什么要学

权限系统决定你敢不敢放手让 agent 干活。放得太紧：每个文件保存都点一次确认，一天点几百次；放得太松：rm -rf、git push --force、读 .env 不再有人拦。成熟用法是把权限当成代码来管理：团队共享一份 allow/deny 清单进 git，个人差异放本地配置，审查时有据可查。这是 Claude Code 用于生产环境的必修课，也是面试里「如何安全使用 coding agent」的标准答案来源。

人话：权限规则就是小区门禁。快递（跑测试）刷白名单直接进；陌生人（改配置）登记放行；劫匪（删库跳表）直接拒之门外。

先建立图像

一次敏感操作的默认流程，与三层配置的优先级：

Claude 想执行 Bash(npm run test)
   ↓ 命中 allow 规则？→ 直接执行
   ↓ 命中 deny  规则？→ 直接拒绝，不执行
   ↓ 其余：弹窗问你
       ├─ Yes（仅这次）
       ├─ Yes, and don't ask again（写入配置）
       └─ No（本次拒绝，它换思路）

配置优先级（高 → 低）：
  企业策略 > 命令行参数 > .claude/settings.local.json
          > .claude/settings.json > ~/.claude/settings.json

跟着做

步骤 1：体验一次完整权限弹窗

新会话里让它执行一条命令：

帮我在项目里跑一下单测

弹窗出现时注意三个选项的含义，本课原则：只对确定安全的操作选 "don't ask again"。

步骤 2：用 /permissions 管理规则

/permissions

面板中可查看与增删 Allow / Ask / Deny 三类规则，选作用域（用户 / 项目 / 本地）。先在这里加两条感受一下：

Allow: Bash(npm run test:*)
Deny:  Read(./.env)

步骤 3：手写团队共享配置

创建 .claude/settings.json（进 git，全团队生效）：

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Edit(.github/**)"
    ],
    "deny": [
      "Read(./.env*)",
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

规则语法要点：Bash(前缀:*) 匹配以该前缀开头的命令；Read/Edit(路径模式) 用 glob；WebFetch(domain:example.com) 限定域名；MCP 工具用 mcp__服务器名__工具名（或 mcp__服务器名 整体放行）。

步骤 4：个人差异放本地文件

创建 .claude/settings.local.json（默认被 git 忽略，只影响自己）：

{
  "permissions": {
    "allow": [
      "Bash(mvn test:*)",
      "Bash(docker compose up:*)"
    ]
  }
}

步骤 5：按任务切权限模式

• 编码日常：默认模式，敏感操作逐次确认。
• 批量小改动：Shift+Tab 一次切到 acceptEdits，文件编辑免确认（Bash 仍受控），改完统一 git diff 审查。
• 只读调研：Shift+Tab 两次切到 plan 模式，物理禁写。

启动时也可指定：

claude --permission-mode acceptEdits

步骤 6：认识高危开关（只了解，不常用）

claude --dangerously-skip-permissions   # 跳过所有权限确认

仅适合无敏感数据的隔离环境（容器/临时虚拟机）。在日常工作机上使用等于把 shell 交给模型裸奔，本课明确不推荐。

讲清楚要点

1. allow / ask / deny 语义：allow 自动放行；ask 强制弹窗（即使命中 allow 也拦截，用于提示性确认）；deny 直接拒绝，模型会收到拒绝反馈并尝试其他路径。
2. deny 优先于 allow：规则冲突时，拒绝生效。因此「默认拒绝、精确放行」比「全部放行、零星拒绝」安全得多。
3. 三层配置各有用途：settings.json 进 git 是团队共识；settings.local.json 是个人沙盒；~/.claude/settings.json 覆盖你所有项目。企业另有统一下发策略，优先级最高。
4. 模式与规则是两套机制：权限模式改变「默认确认强度」（会话级、随手切），规则清单定义「长期边界」（配置级、进版本库）。日常配合：规则管长期，模式管当下。
5. 安全底线是版本控制：再严的规则也有漏网，git 才是最终兜底——审查用 git diff，回滚用 git restore，历史追溯用 git log。

你可能会懵的地方

• 规则匹配是安全过滤吗？能防注入吗？ 它是便利与边界控制，不是安全沙箱。命令匹配基于前缀模式，复杂 shell 拼接可能绕过字面匹配。高危环境要在容器等隔离层做防护，规则只作为第一道闸门。

• 为什么 deny 了它还在「想办法」？ 拒绝会作为结果反馈给模型，它可能尝试替代路径（比如不读 .env 而问你要配置）。这是预期行为；若某类操作完全不允许，用 deny 明确列出该路径的目标资源。

• acceptEdits 会自动执行 Bash 吗？ 不会。它只对文件编辑类工具免确认，命令执行仍走原有规则与确认。所以它是「提效但可控」的中间档。

• 团队成员绕过项目规则怎么办？ 项目规则可以被其个人本地配置覆盖（本地优先级更高）。需要强制一致时依赖企业策略层（组织统一下发），或改用容器化受控环境执行。

• 怎么审计 agent 到底做了什么？ 会话内看工具调用记录（--verbose 更详细）；仓库里 git log/git diff 看实际变更；CI 场景在流水线层留存日志。三者结合形成审计链。

错法对照

错法	问题	正解
见弹窗就选 don't ask again	一周后等于没有权限系统	只白名单化确定安全的命令
deny 不写，全靠弹窗把关	一次手滑全盘失守	高危操作（.env、force push、rm -rf）硬 deny
把 bypass 权限开关当日常	任何破坏性命令无人拦截	仅隔离环境使用
团队规则写在各自 local 里	无版本、无共识、无法审计	共性规则进 .claude/settings.json + git
只信权限规则不做代码审查	规则≠正确，改错文件照样放行	权限管「能不能」，diff 管「对不对」

卡点急救

1. 同一操作反复弹窗：把该命令前缀加入 allow（/permissions 或直接编辑 settings.json），注意用 :* 覆盖参数变化。
2. 误放行了危险命令：立即从 allow 中删除该规则；git reflog/git diff 排查损失；必要时回滚相关提交。
3. 配置改了不生效：检查文件位置与 JSON 语法（/doctor 可体检）；规则在新会话加载，改动后重启会话验证；注意上层配置是否已被更高优先级覆盖。

面试常问

• 如何在团队内落地 coding agent 的权限治理？ 分层治理：团队 allow/deny 清单进 git（settings.json）形成共识与审计依据；个人差异进 local 配置；高危操作一律 deny；配合权限模式按任务放权；最终以 git 审查兜底，CI 环境进一步用白名单与隔离环境收敛。

• Claude Code 的权限模型有哪几层防线？ 交互确认（默认弹窗）、权限模式（plan 只读等）、规则清单（allow/ask/deny）、Hooks（工具调用前后的强制检查脚本）、企业策略（组织级强制）。纵深防御，各管一段。

• allow 规则和 Hooks 拦截有什么区别？何时用哪个？ 规则是静态匹配、用于「常规白名单/黑名单」，简单高效；Hooks 是任意脚本逻辑、用于「需要上下文判断的策略」（如扫描敏感信息、按分支限制操作）。简单规则用前者，复杂策略用后者。

自测三问

1. allow、ask、deny 三类规则分别对应什么行为？谁优先？
2. 三层 settings 文件的位置、进不进 git、优先级顺序？
3. --dangerously-skip-permissions 适合什么环境？日常为什么不该用？

小结一句话

权限治理 = 精确 allow 免打扰 + 关键操作 ask + 危险操作硬 deny，团队共识进 git、个人差异进本地、模式随手切、git diff 兜底——敢放权的前提是边界清晰。

延伸

• 权限管理官方文档
• 下一课：MCP 与插件——通过开放协议把数据库、浏览器、监控系统接进 Claude Code，扩展它的能力半径。