本节目标

完成本节后，你将能够：

1. 理解 Claude Code 四级权限模型的每一层含义和适用场景

2. 创建并精细配置 .claude/settings.json

3. 区分 allowedTools 和 denyCommands 的使用场景

4. 正确保护敏感文件（密钥、证书、环境配置）

5. 评估 --dangerously-skip-permissions 的风险并做出明智选择

---

核心知识点

为什么权限系统是 Claude Code 的基石

在传统的 IDE 插件中，AI 只能"建议"代码——你可以看到建议，但最终是否采纳由你手动操作。Claude Code 打破了这层屏障：它能直接读写文件、执行终端命令、访问网络。

这种能力是双刃剑：

• 好的一面：AI 可以独立完成跨文件的复杂任务，真正提升效率

• 风险的一面：一个错误的 rm -rf 命令或一个疏忽的数据库修改可能造成灾难性后果

Claude Code 的权限系统就是为了解决这个矛盾而设计的：让 AI 有能力做事，但每一件有风险的事都必须经过你的批准。

四级权限模型

Deny（拒绝）  →  Ask（询问）  →  Allow（允许）  →  Auto-Accept（自动接受）
  ↑ 最安全                                ↑ 最便捷
  但最受限                                但风险最高

级别 1：Deny（拒绝）——"这件事绝对不能做"

被设为 Deny 的操作，Claude Code 完全不会尝试执行。即使 AI 认为"最好的方案是删除这个目录"，如果你在设置中将 rm -rf 设为 Deny，它根本不会提出这个方案。

何时使用：

• 保护生产环境的敏感命令

• 禁止对关键配置文件的修改

• 阻止可能造成不可逆后果的操作

级别 2：Ask（询问，默认）——"做之前问我"

这是 Claude Code 的默认行为。当 AI 想要修改文件或执行命令时，终端会弹出确认提示。你需要手动选择 Approve 或 Deny。

何时使用：

• 所有新项目的前两周（建立信任期）

• 对项目代码库还不熟悉的阶段

• 团队中的新手成员

级别 3：Allow（允许）——"这个目录下的文件可以自由修改"

你可以将特定目录或命令类型设为 Allow，Claude Code 在匹配范围内不再每次询问。

何时使用：

• 项目的 src/ 目录（你频繁迭代代码的地方）

• 安全的只读命令（ls、cat、git status、git diff）

• 你已经完全信任 AI 的操作区域

级别 4：Auto-Accept（自动接受）——"我相信你，放手做"

所有操作自动批准，Claude Code 不会弹出任何确认提示。

何时使用：

• 几乎从不。这个模式是给自动化 CI/CD 流水线或完全沙箱化的环境设计的。

• 如果你在一个手动开发环境中使用 Auto-Accept，你等于放弃了所有安全检查。

.claude/settings.json 配置详解

.claude/settings.json 是你精确控制权限的地方。它位于项目根目录的 .claude/ 文件夹中（注意这是隐藏目录）。

一个生产级的配置示例：

{
  "permissions": {
    "allow": [
      "Bash(curl:*)",
      "Bash(git:status,diff,log,add,commit,branch,checkout)",
      "Bash(npm:test,run,install)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(node:*)",
      "Bash(tsc:*)",
      "Read(*/src/**)",
      "Write(*/src/**)",
      "Edit(*/src/**)"
    ],
    "deny": [
      "Bash(rm:-rf, -r, -f)",
      "Bash(sudo:*)",
      "Bash(chmod:*)",
      "Bash(chown:*)",
      "Write(**/.env)",
      "Write(**/.env.*)",
      "Write(**/*.pem)",
      "Write(**/*.key)",
      "Write(**/credentials.*)",
      "Write(**/.git/config)",
      "Write(**/package-lock.json)",
      "Write(**/yarn.lock)"
    ],
    "defaultMode": "ask"
  }
}

allowedTools 和 denyCommands 的区别

这两个概念常常被混淆，但它们的作用层面完全不同：

概念	控制什么	配置位置	示例
allowedTools	哪些工具类别可以使用	settings.json 的 permissions.allow	允许 Read 但禁止 Write
denyCommands	在允许的工具中，哪些具体操作被禁止	settings.json 的 permissions.deny	允许 Bash 但禁止 rm -rf

层级关系：

allowedTools 是第一道门：这个工具能不能用？
  ↓ 如果能用
denyCommands 是第二道门：这个工具中的哪些具体操作不能做？

实际例子：

• allowedTools 允许了 Bash 工具

• denyCommands 禁止了 Bash(rm:*) 和 Bash(sudo:*)

• 结果：Claude Code 可以运行 npm test，但不能运行 rm -rf / 或 sudo 命令

敏感文件保护机制

Claude Code 内置了一套敏感文件检测机制。以下类型的文件默认受到额外保护：

高风险文件（即使 Allow 模式也需要额外确认）：

• .env、.env.local、.env.production —— 环境变量和密钥

• *.pem、*.key、*.cert —— 证书和私钥

• credentials.*、secrets.* —— 凭据文件

• .git/config —— Git 配置

• *.p12、*.pfx —— PKCS12 密钥库

为什么这些文件特殊： 即使你把 Write(*/src/**) 设为 Allow，Claude Code 也会在修改以上类型文件时额外弹出警告。这是最后的防线——防止 AI 意外修改或泄露敏感信息。

--dangerously-skip-permissions 的真实风险

这个参数的名字本身就说明了它的危险程度。它的作用是：跳过所有的权限检查，让 Claude Code 自由执行任何操作。

claude --dangerously-skip-permissions

你绝对不应该在以下场景使用它：

• 在你的主力开发机器上

• 在包含真实数据的项目目录中

• 在没有版本控制的目录中

• 在你不完全理解的代码库中

唯一合理的使用场景：

• Docker 容器中的完全隔离环境

• 临时的 CI/CD 沙箱

• 只包含测试数据且完全可丢弃的实验目录

---

实操步骤

步骤 1：创建并理解默认的权限配置

# 在测试项目中创建 .claude 目录
mkdir -p .claude

手动创建 .claude/settings.json，从最保守的配置开始：

{
  "permissions": {
    "defaultMode": "ask"
  }
}

这表示：所有操作都需要询问。这是最安全的起点。

步骤 2：添加第一条 Allow 规则

在 Claude Code 交互模式中，你会发现每次运行 npm test 都需要手动批准。这很烦人。所以添加第一条 Allow 规则：

{
  "permissions": {
    "allow": [
      "Bash(npm:test,run test,run)"
    ],
    "defaultMode": "ask"
  }
}

现在 Claude Code 运行 npm test 时会自动通过，不需要你手动批准。

步骤 3：逐步完善配置文件

随着你对项目的熟悉，逐步增加 Allow 条目和 Deny 条目。

推荐的渐进路径：

第 1 周（信任建立期）：

{
  "permissions": {
    "allow": [
      "Bash(npm:test,run,ls,cat,node)",
      "Bash(git:status,diff,log,branch)"
    ],
    "defaultMode": "ask"
  }
}

第 2 周（部分信任期）：

{
  "permissions": {
    "allow": [
      "Bash(npm:*)",
      "Bash(git:*)",
      "Bash(ls:*,cat:*,echo:*)",
      "Read(*/src/**)",
      "Write(*/src/**)",
      "Edit(*/src/**)"
    ],
    "deny": [
      "Bash(rm:-r*)",
      "Bash(git:push, push --force)",
      "Write(**/.env*)"
    ],
    "defaultMode": "ask"
  }
}

步骤 4：测试权限配置是否生效

在配置文件中加入一条测试规则：

"deny": [
  "Write(**/DO_NOT_TOUCH.md)"
]

创建一个受保护的文件：

echo "This file should never be modified" > DO_NOT_TOUCH.md

然后在 Claude Code 中尝试：

修改 DO_NOT_TOUCH.md，加一行注释

观察：Claude Code 应该拒绝这个操作，并告诉你这个文件在 deny 列表中。

步骤 5：敏感文件保护验证

echo "API_KEY=sk-ant-secret123" > .env

在 Claude Code 中尝试：

修改 .env 文件，把 API_KEY 改成另一个值

即使你没有在 settings.json 中显式禁止 .env，Claude Code 也应该弹出额外的安全警告。

---

避坑指南

坑 1：一次性 Allow 太多

很多新手上手第一天就写了这样的配置：

{
  "permissions": {
    "allow": [
      "Bash(*)",
      "Write(*)",
      "Edit(*)",
      "Read(*)"
    ]
  }
}

这等于放弃了所有安全检查。你给了 AI 随心所欲改任何文件、执行任何命令的权限。

正确做法：渐进式配置。每次只 Allow 那些你发现"每次都要手动批准太烦了"的操作。一周后你的配置会自然收敛到最合适的状态。

坑 2：deny 规则配置不精确

// 错误：意图是禁止删除操作，但实际上只禁止了 rm -rf
{
  "deny": ["Bash(rm:-rf)"]
}
// Claude Code 仍然可以执行 rm -r、rm -f、rm file.txt

// 正确：禁止所有 rm 操作
{
  "deny": ["Bash(rm:*)"]
}

deny 规则的匹配是精确的。rm:-rf 只匹配 rm -rf 这个精确命令，不匹配 rm -r 或 rm -f。用通配符 * 来覆盖变体。

坑 3：在不同项目中复用同一个 settings.json

你的个人博客项目的权限配置不应该被直接复制到公司产品的代码库中。不同项目有不同的安全需求。

正确做法：

• 每个项目独立配置 .claude/settings.json

• 用一个"基础模板"作为起点，然后根据项目调整

• 配置文件和 CLAUDE.md 一起纳入版本控制

坑 4：忘记了 git push 是需要保护的

很多新手把 git:* 设为 Allow，然后某天 Claude Code 在执行任务时顺手做了个 git push --force。

// 安全的 git 配置
{
  "allow": [
    "Bash(git:status,diff,log,add,commit,branch,checkout,stash)"
  ],
  "deny": [
    "Bash(git:push, push --force, push --force-with-lease)",
    "Bash(git:reset --hard)"
  ]
}

永远不要让 AI 有权限执行破坏性的 Git 操作。

---

课后作业

1. 配置审计：检查你当前项目的 .claude/settings.json，列出所有 Allow 规则。对每条规则问自己"这条真的需要吗？"——删除任何可以去掉的。

2. 安全测试：在你的配置中故意加入一条 deny 规则（如禁止修改特定文件），然后让 Claude Code 尝试修改该文件。验证 deny 是否生效。

3. 场景演练：假设你的项目是一个电商网站，写出你会为以下文件/目录配置什么级别的权限：src/、migrations/、.env.production、database/、tests/。

4. 团队讨论：如果你的团队也在使用 Claude Code，组织一次 15 分钟的讨论，对齐权限配置的标准。不同开发者对"什么操作需要确认"可能有完全不同的理解。

---

总结

Claude Code 的权限系统不是"阻碍你工作的枷锁"，而是"让你安心放手给 AI 的安全网"。

四个核心原则：

1. 从保守开始，逐步开放：新项目永远从 defaultMode: "ask" 开始

2. allow 要窄，deny 要宽：只 Allow 那些确实需要自动化的操作；Deny 所有可能造成伤害的操作类别

3. 敏感文件有双重保护：即使 Allow 了 Write 权限，.env、证书、密钥文件也会触发额外警告

4. 永远不要在主力环境使用 --dangerously-skip-permissions：这个参数的名字就是它的说明书——它真的很危险

记住：好的权限配置会让你感觉不到权限系统在阻碍你，同时在你（或 AI）即将犯错时及时拦住。这是一种微妙的平衡——需要时间和经验来打磨。下一节我们会汇总所有新手常见的陷阱，帮助你更快达到这种平衡。