这是Claude Code通关手册的第二篇，上一篇我们初步了解了Claude Code，这一篇要解决新手最头疼的问题——权限系统，搞清Claude Code的权限分配，让Claude Code真正能为我们提效
使用Claude Code的开发者，想必都经历过这样的崩溃场景：
“我要读取pom.xml文件，可以吗？”——同意
“我要将依赖写入pom.xml文件，可以吗？”——同意
当第10次弹出权限请求时，大多数人早已忍无可忍，只想大喊：”我全都同意了，你自己去运行吧！”
然而，当我们真正去查找解决方案时，才发现Claude Code有一个--dangerously-skip-permissions参数可以跳过权限确认。从名称就能看出，这是一个”危险”的选项。
我们并不需要采取如此极端的方式。权限系统实际上是我们的安全屏障，无需给予Claude Code全部权限。合理分配权限，能够在效率与安全之间取得完美平衡。
本文将教你如何善用权限系统，将那些烦人的权限提示转化为得心应手的工具，让它们从拦路虎变成遥控器。
五种权限模式：从保姆级守护到全自动飙车
Claude Code内置了五种权限模式，覆盖从最保守到最激进的所有场景，可以在会话中按shift + tab快速进行切换。
| 模式 | 行为 | 适用场景 |
|---|---|---|
| default（默认） | 读文件自动通过 写文件需要确认 命令需要确认 |
新手优化 |
| accept edits on | 读文件自动通过 写文件自动通过 命令需要确认 |
日常开发模式 |
| plan mode on | 只能读和分析 不能写和执行命令 |
探索不熟悉的代码库 代码审查、分析 |
| dontAsk | 读写命令全自动 但是不跳过安全检查 |
严格锁定、高度安全的环境 需要注意的是所有未经明确授权的操作都会被静默拒绝 可能会导致执行任务时由于权限受阻，影响任务完成 |
| bypass ⚠️ | 完全跳过所有检查 目前权限级别最高的模式 |
完全自动化的 CI/CD 或容器环境 |
在交互模式中按 Shift+Tab，你会看到状态栏在三种模式间循环：
normal-mode → ⏵⏵ accept edits on → ⏸ plan mode on → normal-mode[!NOTE]
dontAsk和bypass模式由于权限较高，无法在会话中进行选择，需要在开启会话时指定># 开启dontAsk模式,通过 `--permission-mode` 参数直接指定 >claude --permission-mode dontAsk ># 开启 bypass 模式 >claude --dangerously-skip-permissions
日常开发推荐使用acceptEdit模式，因为在写代码这件事上，大概率是希望 Claude 直接改的——毕竟你都让它写代码了，肯定是希望它直接写入文件。但执行 shell 命令（比如 mvn depoly、git push）的时候，你还是想看一眼再确认。
你也可以直接在配置文件中灵活配置可执行的操作，这正是接下来将要讲述的内容。
项目自定义权限：从统一守则到私人保镖
通用权限规则能解决 80% 的日常场景，但每个项目都有自己的脾气。这时候，就需要你亲自给 Claude Code 下达“私人保镖”级别的专属指令——让它知道：在这个项目里，哪些命令可以闭眼通过，哪些操作必须反复确认。
配置文件在哪里？
| 配置文件位置 | 适用场景 |
|---|---|
| ~/.claude/settings.json | 全局配置，所有项目通用 对 Claude Code 的底线要求 |
| 项目根目录/.claude/settings.json | 项目级配置，提交到 Git 跟团队共享 这个项目专属的权限规则 |
| 项目根目录/.claude/settings.local.json | 个人本地配置，不提交到 Git 你自己的偏好，不影响队友 |
优先级：local > project > global
配置文件实操
还需要手动维护项目的配置文件吗？那也太落后了。在Claude Code的会话中，直接让它帮你生成一份项目维度的配置文件吧。
请在当前项目根目录下创建 .claude/settings.json 配置文件，采用 allow/ask/deny 的权限配置模式
具体要求：
1.先扫描分析项目的技术栈（如 Node.js、Python、Java、Go 等）和常用命令（构建、测试、lint、启动等）。
2.根据项目实际命令（如 npm test → Bash(npm test *)，python manage.py runserver → Bash(python manage.py runserver)）动态填充 allow 列表。
3.增加常见安全规则（如rm -rf、.env 读取等）。Claude Code会在项目根目录/.claude/settings.json中生成一份配置文件，我们可以修改这个配置文件来控制我们的权限。
一个最简单的权限配置文件如下:
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Read",
"Edit(./src/**)",
"Write(./src/**)",
"MultiEdit(./src/**)",
"Bash(mvn clean)",
"Bash(mvn compile)",
"Bash(mvn package)",
"Bash(mvn install)",
"Bash(npx tsc --noEmit)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git add *)",
"Bash(git commit *)",
"Bash(git log *)",
"Bash(ls *)",
"Bash(cat *)",
"Bash(mkdir *)"
],
"ask": [
"Bash(git push *)",
"Bash(npm deploy)",
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(curl *)",
"Read(./.env*)",
"Read(./secrets/**)",
"Edit(./.env*)",
"WebFetch"
]
}
}这份配置翻译成人话就是：
allow（自动通过）：读任何文件、编辑 src 目录下的代码、跑开发/构建/测试命令、常规 Git 操作——这些都是日常高频操作，不用每次都问我。
ask（问我一声）：推代码到远程、安装新依赖、执行数据库迁移——这几个操作有一定风险，让我确认一下。
deny（绝对禁止）：删除操作、sudo 提权、读取环境变量文件——不管什么情况，这些操作一律拦截。
==deny 永远优先级最高==。就算你在 allow 里写了允许读 .env 文件，只要 deny 里也有这条规则，Claude 就死也读不了。这是安全底线，不可妥协。
Claude Code所有的配置就都是在这三层里做文章。
/permissions 命令：不用手写 JSON
如果你不想手动编辑 JSON 文件，Claude Code 提供了交互式配置界面。在会话中输入：
/permissions它会弹出一个交互式菜单，供你添加或移除权限规则。此外，当 Claude 询问你是否允许某个操作时，选择”Always allow”选项会自动将该规则添加到你的允许列表中。
这种”在使用过程中逐步配置”的方式非常符合用户习惯——系统首次询问时，用户同意并勾选”以后都允许”，后续便不再重复询问。
安全最佳实践
权限配得再宽松，这三条红线不能碰：
红线一：永远不要允许看不懂的 Bash 命令
Claude 有时会生成复杂的 shell 命令。如果你不理解其用途，切勿直接执行。应先要求 Claude 解释命令的具体功能和目的，确认安全无误后再决定是否执行。
红线二：.env 文件必须列入拒绝访问名单
你的 .env 文件包含数据库密码、API Key 等敏感信息。请务必将 Read(./.env*) 和 Edit(./.env*) 权限加入拒绝列表，彻底封堵这一安全隐患。
红线三：生产环境操作需使用 plan 模式
在生产代码库中工作时，首先切换至 plan 模式。让 Claude 仅进行分析和方案制定，不直接执行任何修改。确认方案安全可行后，再切换回 acceptEdits 模式执行具体操作。这如同手术前先进行影像检查明确情况——切勿盲目动手操作。
一份你能直接复制的全局配置
最后，送你一份经过实战验证的全局配置模板。把它放到 ~/.claude/settings.json，作为你所有项目的基础配置。
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Read",
"Bash(ls *)",
"Bash(cat *)",
"Bash(head *)",
"Bash(tail *)",
"Bash(wc *)",
"Bash(find *)",
"Bash(grep *)",
"Bash(echo *)",
"Bash(mkdir *)",
"Bash(git status)",
"Bash(git log *)",
"Bash(git diff *)",
"Bash(git branch *)",
"Bash(git show *)",
"Bash(node --version)",
"Bash(npm --version)",
"Bash(npx tsc --noEmit)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env*)",
"Read(./secrets/**)",
"Read(./**/credentials*)",
"Edit(./.env*)",
"Edit(./secrets/**)",
"WebFetch"
]
}
}这是全局的”安全底线”。在具体项目中，你再通过项目级的 .claude/settings.json 添加项目特有的 allow 规则（比如 mvn clean、mvn install 之类的命令）。
采用全局与项目两层协作机制：全局配置作为安全基线及通用便利性设置，项目配置则专注于特定项目需求，仅对当前项目生效。通过这套配置体系，权限提示可减少80%以上，同时确保安全基线保持不变。
本篇小结
三个核心收获：
第一：权限系统的本质是三层过滤器——deny（拒绝）> ask（询问）> allow（通过），优先级从高到低。理解这一模型后，所有配置都将变得水到渠成。
第二：在五种权限模式中，acceptEdits 是日常开发的首选——代码编辑自动通过，命令执行需要确认。按 Shift+Tab 可随时切换。
第三：全局与项目两层协作机制配合使用，既便捷又安全。
