第 6 章 · 权限模型与安全设置
本章目标：理解 Claude Code 的权限模型，掌握 allowedTools/deny 配置、项目信任机制与密钥保护，遵循最小权限原则安全地使用 AI 编码助手。
6.1 权限模型概述
Claude Code 采用分层权限模型：默认情况下，读取文件和搜索代码不需要确认，但写入文件、执行 Bash 命令、安装依赖等"有副作用"的操作需要用户逐次批准。
text
┌──────────────────────────────────────────────┐
│ 权限层级 │
├──────────────────────────────────────────────┤
│ 只读操作（自动允许） │
│ Read / Grep / Glob / LS │
├──────────────────────────────────────────────┤
│ 写入操作（需批准或预配置） │
│ Write / Edit / NotebookEdit │
├──────────────────────────────────────────────┤
│ 执行操作（需批准或预配置） │
│ Bash / WebFetch / mcp__* │
├──────────────────────────────────────────────┤
│ 危险操作（始终需人工确认） │
│ rm -rf / curl | sh / 密钥访问 │
└──────────────────────────────────────────────┘设计理念
Anthropic 的安全哲学是"默认安全，显式放开"——你告诉 Claude 它能做什么，而不是列出它不能做什么。这比黑名单模式更不容易遗漏。
6.2 allowedTools：预授权工具
在 .claude/settings.json（项目级）或 ~/.claude/settings.json（全局级）中配置：
json
{
"permissions": {
"allow": [
"Bash(npm run test:*)",
"Bash(git commit:*)",
"Bash(git push origin feature/*)",
"Edit",
"Write"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(curl * | sh)",
"Read(.env*)",
"Read(**/*.pem)"
]
}
}常用规则语法：
| 规则 | 含义 |
|---|---|
Bash(git commit:*) | 允许所有以 git commit 开头的命令 |
Edit | 允许所有文件编辑 |
WebFetch(domain:api.github.com) | 仅允许请求该域名 |
mcp__github__create_issue | 允许调用特定 MCP 工具 |
Read(.env*) | 禁止读取环境变量文件 |
6.3 --dangerously-skip-permissions
bash
# 跳过所有权限检查 — 极度危险！
claude --dangerously-skip-permissions这个标志会跳过所有工具调用确认。适用场景极其有限：
- ✅ 在 Docker 容器内运行隔离任务；
- ✅ CI/CD 流水线中受限环境下的自动化；
- ❌ 在宿主机上日常开发——绝对不要。
dockerfile
# Dockerfile — 安全的无人值守示例
FROM node:20-slim
RUN curl -fsSL https://claude.ai/install.sh | bash
WORKDIR /workspace
COPY . .
CMD ["claude", "-p", "Run all tests and fix failures", \
"--dangerously-skip-permissions"]容器内即使 Claude 做了破坏性操作，也只影响容器层，不波及宿主机。
6.4 项目信任机制
首次进入一个新目录时，Claude Code 会弹出信任提示：
text
⚠️ Do you trust the files in this folder?
/home/user/new-project
Files from untrusted sources may contain malicious
instructions that could affect Claude's behavior.选择"Yes, proceed"后：
- 该目录被标记为已信任；
- 项目级
.claude/settings.json中的规则才会生效； - CLAUDE.md 中的自定义指令才会加载。
克隆仓库的安全风险
从 GitHub 克隆他人项目时，恶意仓库可能在 .claude/settings.json 中注入危险规则，或在 CLAUDE.md 中嵌入提示注入指令。永远先审查再信任：
bash
git clone https://github.com/xxx/repo.git
cd repo
# 先看有没有可疑配置
cat .claude/settings.json 2>/dev/null
cat CLAUDE.md 2>/dev/null | head -30
# 确认无异常后再启动
claude6.5 最小权限原则实践
场景一：只让 Claude 写代码，不让它跑命令
json
{
"permissions": {
"deny": ["Bash"]
}
}场景二：只读分析——禁止一切修改
bash
claude --allowedTools "Read,Grep,Glob,LS" \
-p "分析这个项目的架构并输出报告"场景三：限定可编辑范围
json
{
"permissions": {
"allow": [
"Edit(src/**)",
"Write(src/**)",
"Bash(npm test:*)"
],
"deny": [
"Edit(infrastructure/**)",
"Write(.env*)"
]
}
}6.6 密钥与环境变量保护
Claude Code 可能通过 Read 或 Bash 接触到敏感信息。防护策略：
json
{
"permissions": {
"deny": [
"Read(.env)",
"Read(.env.local)",
"Read(**/secrets/**)",
"Read(**/*credential*)",
"Bash(echo $AWS_SECRET_ACCESS_KEY)",
"Bash(cat *key*)"
]
}
}额外建议：
- 使用
.claudeignore类似.gitignore，排除敏感目录不被索引； - 密钥管理工具：用
direnv或 Vault 注入环境变量，而非明文存储； - 定期审计：检查
~/.claude/projects/下是否有意外记录的敏感对话内容。
本章小结
- 权限三层级：只读自动放行 → 写入需批准 → 危险始终确认；
settings.json的allow/deny数组实现细粒度控制；--dangerously-skip-permissions仅限容器等隔离环境；- 新目录必须通过信任提示才加载项目级配置；
- 永远遵循最小权限原则，用 deny 列表保护密钥文件。
🧪 随堂测验
点击你认为正确的选项。答错时会展示正确答案与原因解析。
1. Claude Code 默认允许哪些操作无需用户确认？
2. --dangerously-skip-permissions 标志的合理使用场景是？
3. 为什么克隆第三方仓库后不应立即信任该项目？
4. 以下哪条 deny 规则能有效保护 AWS 密钥？
🛠️ 动手实践
- 为你的项目创建
.claude/settings.json：允许npm test和git commit，但拒绝读取.env文件。 - 用
claude --allowedTools "Read,Grep,Glob"启动只读模式，让它分析项目架构。 - 审查一个开源项目的
.claude/settings.json和CLAUDE.md，评估是否存在安全隐患。
完成练习后，进入下一章：多轮会话与上下文管理。