CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
Claude Code 实战入门/课时/权限与安全
RawBlame
课时目录12 节

Claude Code 实战入门

  1. 01Claude Code 概览
  2. 02工作流与 Plan 模式
  3. 03CLI 与会话
  4. 04模型与定价
  5. 05上下文与 CLAUDE.md
  6. 06权限与安全
  7. 07MCP 与插件
  8. 08Skills 与子代理
  9. 09Hooks 事件
  10. 10扩展与规模化
  11. 11内置工具集
  12. 12综合练习

权限与安全

Permission modes 与最佳实践。

30 分钟

权限与安全

这一课你将能做到

  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,扩展它的能力半径。
加载本节练习…
← 上一课上下文与 CLAUDE.md下一课 →MCP 与插件