用 Claude Code 做批量重构之前，我以为最大的成本是模型“理不理解需求”。真正上手之后才发现，成本是终端里一个接一个的确认弹窗：改一个文件弹一次，跑一条命令再弹一次，有时候同一个操作还会被拆成两次确认。本来是几分钟能跑完的改动，硬生生被确认弹窗拖成了“人肉连点器”。这篇文章把我在项目中验证过的启动参数和权限配置完整梳理一遍，从默认弹窗模式一路讲到完全无人值守，同时说清楚哪些地方可以放开、哪些地方必须守住。适合已经用上 Claude Code、但还在被弹窗打断节奏的开发者。
1. 弹窗从哪来：Claude Code 的权限模型与三类操作门禁
1.1 三类操作，三道不同级别的门
Claude Code 在终端里的每个动作，本质上都是通过工具调用完成的。它和你在浏览器里聊天不一样，它有真实的能力边界：能读你的文件、改你的文件、执行 shell 命令、访问网络资源。这些能力按类别分，大致就是三组：
| 工具类别 | 典型工具 | 默认确认行为 | 主要风险 |
|---|---|---|---|
| 文件系统 | Read、Write、Edit、MultiEdit | 读文件通常直接放行或仅首次确认；写文件、编辑文件需要确认 | 误覆盖代码、读取敏感文件 |
| 命令执行 | Bash | 每条命令执行前都要确认 | 高危命令、破坏性环境变更 |
| 网络访问 | WebFetch、WebSearch | 发起请求前确认 | 内容外传、外部数据进入对话 |
很多人只知道“弹窗很烦”，但没注意弹窗的粒度是不一样的。比如Read这类只读操作，默认就宽松得多，因为读操作不改变环境，风险是“信息泄露”而不是“环境破坏”。但风险依然存在：如果模型读取了.env、SSH 私钥这类文件，内容进入对话上下文之后，一旦后续又调用了网络工具，敏感信息就可能被带出去。所以权限配置里不能只防写，也要防读。
1.2 “最小权限”设计 vs 开发者的“确认疲劳”
弹窗设计的初衷很容易理解：一个能执行命令、能改文件的智能体，行为未经审查就跑起来，风险是不可控的。这就像新同事入职第一天，你不会直接把服务器 root 密码给他。每做一步确认，本质上是“最小权限”原则的落地。
但问题也出在这里。人类同事做事会有上下文，你确认一次方向之后，中间步骤就不需要逐个追问了。模型不一样，它几十步操作可以连续执行，每一步都弹窗，用户就成了纯机械化确认的回车机器。时间一长，人就会疲劳，疲劳就会想走捷径。
我见过不止一个开发者为了省事，直接把跳过权限确认的参数写进日常命令别名里。直到某一次模型在重构时执行了git clean -fd，未提交的改动和临时文件被清得干干净净，才意识到问题。核心教训就一句话：不是所有操作都可逆。可逆的操作可以放开，不可逆的操作必须留一道闸。后文所有配置思路，都是围绕这句话展开的。
2. 启动参数全景拆解：从 --dangerously-skip-permissions 到规则化放行
2.1 两个直接“跳过一切”的入口
先说最激进的参数：--dangerously-skip-permissions。启动时加上它，会话内所有权限确认都会关闭，文件操作、命令执行、网络访问一律不弹窗。名字里的dangerously不是吓唬人，它跳过的不是某一类工具，而是所有工具的全部确认逻辑。
claude --dangerously-skip-permissions官方也提供了对应的环境变量方式，效果等同：
export CLAUDE_CODE_DANGEROUSLY_SKIP_PERMISSIONS=1 claude命令行参数适合临时调试，环境变量适合想长期默认生效的场景。但我个人强烈不建议把这条路写进日常别名，它只适合以下情形：一次性任务且工作区已经提交干净、在容器或临时 worktree 里运行、你明确知道当前任务每一步的操作边界。
如果你发现自己每天都在用这个参数，那说明你的真实需求不是“所有权限全跳过”，而是“流程里弹窗太多，需要一套更细的规则”。
2.2 四个权限模式：default、acceptEdits、bypassPermissions、plan
除了全跳过，Claude Code 还提供了几个权限模式，用--permission-mode指定。它们之间有明显的保守到激进的梯度：
| 模式 | 启动写法 | 行为 |
|---|---|---|
| default | claude --permission-mode default | 默认行为，按配置询问 |
| acceptEdits | claude --permission-mode acceptEdits | 自动接受文件编辑，但 Bash 命令仍确认 |
| bypassPermissions | claude --permission-mode bypassPermissions | 完全跳过权限确认 |
| plan | claude --permission-mode plan | 只读模式，不能写文件、不能跑有副作用的命令 |
这里我要重点解释acceptEdits，它是我日常使用的主力模式。原因就是前面说的可逆性判断：文件编辑是相对可逆的操作，改错了可以 diff、可以撤销、可以回滚；而命令执行则是相对不可逆的，删了文件、推了远端、跑了数据库脚本，后悔成本很高。让模型自由改文件、但命令动手前问一声，是性价比最高的组合。
plan模式也很有用。它让模型处于只读状态，可以读代码、分析目录结构、制定实施方案，但不能写文件、不能执行有副作用的命令。复杂任务先让它出方案，人确认后再切换模式执行。关键是，你不需要退出重开：在会话里直接用/permissions命令就能动态切换。我在批量重构时反复用这个组合，先规划、后执行，非常稳。
2.3 规则化放行：--allowedTools 与 --disallowedTools
跳过确认是“一刀切”，更精细的做法是规则化放行：只对特定工具、特定命令、特定路径放行。两个参数分别是--allowedTools和--disallowedTools。
claude \ --allowedTools "Bash(npm run build), Bash(npm test), Write(src/**)" \ --disallowedTools "Bash(rm -rf *), Bash(git push --force)"这里的写法是工具名(参数特征)，括号里的内容会去匹配实际工具调用。比如：
Bash(npm run build)只放行这一条命令；Bash(npm run *)放行所有以npm run开头的命令；Write(src/**)放行对 src 目录下所有文件的写入；- 不带括号的
Bash表示放行所有 Bash 工具调用，非常危险，慎用。
--disallowedTools的优先级更高。如果一个操作同时命中了 allow 和 deny，最终会以 deny 为准。这条特性很适合用来做“无论如何都不能碰”的命令清单，即使你在配置里不小心放大了 allow 范围，deny 还能兜底。
2.4 自动化相关参数：-p、--output-format、--max-turns
真正做无人值守时，光靠权限参数还不够，还需要几个会话控制参数：
-p / --print：非交互模式，适合脚本和 CI。任务执行完直接输出结果，不会进入交互界面。--output-format json：把结果按 JSON 输出，方便后续程序解析。--max-turns N：限制任务最多迭代多少轮，防止模型在某个问题上反复转圈。-c / --continue：继续上一次会话；--resume <session-id>可以精确恢复到某个历史会话。
举个例子，在命令行里跑一个只读分析任务：
claude -p "统计 src 目录的 TODO 数量并按文件排序" \ --output-format json \ --max-turns 20这种组合方式特别适合接进流水线：输出是结构化的 JSON，轮数有限制，不会因为模型“想太多”而无限耗时间。如果再配合一个--append-system-prompt参数，比如“所有命令执行前先说明用途，不要使用删除类命令”，模型在无人值守时的行为会更克制。这个参数可以在不修改系统级提示词的情况下，给当前会话追加额外的行为约束。
3. settings.json 精细打磨：allow / ask / deny 三段式权限规则
3.1 配置文件的层级：用户级、项目级与本地覆盖
启动参数适合临时调整，但权限规则的“主战场”其实是配置文件。Claude Code 会按层次读取三个位置的配置：
| 配置层级 | 文件路径 | 影响范围 |
|---|---|---|
| 用户级 | ~/.claude/settings.json | 当前用户所有项目 |
| 项目级 | .claude/settings.json | 当前项目，通常会入库、团队共享 |
| 本地级 | .claude/settings.local.json | 当前项目，只对本机生效，应加入 .gitignore |
优先级是本地级覆盖项目级，项目级覆盖用户级；启动时的命令行参数又可以在本次会话内覆盖这些文件配置。我的习惯是：团队级规则放项目级配置，个人偏好放settings.local.json。比如团队统一允许npm run build、npm test，但我不想让它自动跑某个发布脚本，就在本地文件里把它改成 ask。
3.2 permissions 块的三个分组：allow / ask / deny
配置文件的权限核心是permissions块，里面有三个分组：
{ "permissions": { "allow": [ "Bash(npm run build)", "Bash(npm test)", "Edit(src/**)", "Write(src/**)" ], "ask": [ "Bash(git push *)", "Bash(gh pr create *)" ], "deny": [ "Bash(rm -rf *)", "Bash(git clean -fd)", "Bash(curl * | bash)", "Read(~/.ssh/*)", "Read(.env)" ] } }三个分组的语义非常直白：allow直接放行，ask继续询问，deny直接拒绝且不给询问的机会。想让弹窗消失，就是把高频操作不断补充进allow；想让危险操作彻底闭嘴，就写进deny。
新手容易犯一个错误：只往allow里加规则，完全不配置deny。这会导致一个问题：你习惯了 allow 的顺畅之后，某天为了赶进度切到了 bypassPermissions 模式，原本靠弹窗拦住的危险操作就全裸奔了。所以 deny 不是可选项，它是整个权限配置的保险丝。
3.3 匹配规则：精确、通配与目录范围
配置规则时，括号内的匹配逻辑值得花点时间理解：
- 精确字符串：
Bash(git diff)只匹配git diff这一条命令； - 通配符：
Bash(git *)匹配所有以git开头的命令；Write(src/**)匹配 src 目录及所有子目录下的文件； - 不写括号：
"Bash"表示放行 / 拒绝该类工具下的所有调用，影响面很大； - 路径匹配基于项目根目录，也支持绝对路径。
这里有个我踩过的坑：第一次配置时，我把Bash(git *)写进了 allow，觉得 git 命令都很安全。结果模型某次执行了git reset --hard HEAD，当天所有未提交的改动全部消失。git 本身不是危险的命令，危险的是 git 的子命令。所以 allow 尽量写成“命令白名单”，而不是“命令前缀整段放行”。npm run *可以，git *最好不要。
3.4 确认工具名：为什么你的规则“写了不生效”
权限规则最常见的失效原因，是工具名写错了。Claude Code 里工具是按固定名称注册的，写错了自然匹配不上。几个常用工具名：
Bash：执行 shell 命令Read：读取文件Write：写入文件Edit：编辑文件MultiEdit：多文件批量编辑WebFetch：抓取网页内容WebSearch：联网搜索Task：派生子任务TodoWrite：管理待办清单
如果想确认实际触发的工具名，有两个办法：会话里输入/status看当前状态和权限模式；启动时加--debug，模型每次调用工具都会打印详细的日志。还有一种笨但有效的办法：在隔离环境里临时放行某一类工具，观察实际调用，再回来细化规则。不要直接在重要仓库里做这种实验。
4. 三种真实场景的“全自动”配置实操
4.1 场景一：本地日常 bug 修复，不想被弹窗打断
最常见的需求：日常让模型改组件、修 bug、跑测试，希望写文件不弹窗，npm run build、npm test这类高频命令不弹窗，但 git push、删除类命令还是要确认。
我的做法是在项目根目录创建.claude/settings.json：
{ "permissions": { "allow": [ "Bash(npm run build)", "Bash(npm test)", "Bash(npm run lint)", "Edit(src/**)", "Write(src/**)", "Read(src/**)" ], "deny": [ "Bash(rm -rf *)", "Bash(git clean -fd)", "Bash(git push --force)" ] } }启动命令：
claude --permission-mode acceptEdits效果是：文件编辑自动接受，常见 npm 命令自动放行；git push、强制删除仍然会拦住你。我在自己项目里跑了一周，90% 的弹窗都消失了，剩下的弹窗基本都是“确实该看一眼”的操作。对于大多数还没尝试过权限配置的开发者，我建议就先从这一套开始，跑几天再按实际情况加规则。
4.2 场景二：批量重构，先规划再执行
单个文件修改用上一套配置就够了，但跨文件批量重构是另一个量级。假设你想让模型把 20 个文件里的某个接口字段统一改名，直接放它跑，方向一旦错了，改动面特别大。
我的操作流程是：
- 启动计划模式：
claude --permission-mode plan - 给模型描述重构目标，让它先列出涉及文件、改动顺序、风险点；
- 人工确认方案没问题；
- 在会话里输入
/permissions acceptEdits，或者直接bypassPermissions； - 模型开始批量修改；
- 全部改完后，用
git diff逐文件核对，再单独跑测试。
plan 模式在这里的价值是“先想后做的闸门”。它不写文件、不跑命令，风险为零。团队里如果有人对 AI 自动改代码不放心，让他先用 plan 模式看方案，通常比直接放它跑更容易建立信任。
还有一个批量重构的小技巧：在提示词里加上“每改完一个模块就运行一次相关测试”。配合 allow 里的测试命令，模型会自动跑，不用等全部改完才发现报错。这种“边改边验”的工作流，稳定性比“全部改完再验证”高很多。
4.3 场景三：CI 与无人值守，自动化任务
无人值守意味着不可能有人坐在终端前点确认，所以权限策略要反过来设计：要么让任务保持在只读范围，要么在隔离环境里放开权限。
我在流水线里跑自动化任务时，常用的是这种组合：
claude -p "扫描当前仓库的 TODO/FIXME，按文件输出统计和上下文" \ --output-format json \ --max-turns 30 \ --permission-mode bypassPermissions \ --disallowedTools "Bash(rm -rf *), Bash(git push *), Bash(curl * | bash)" \ --settings ci-settings.json这里我敢用bypassPermissions，是因为任务本身是只读分析，加上命令级 deny 仍然挡在工具调用前面，再加上流水线跑在干净的临时目录或新 clone 中，出问题也不污染本地环境。--max-turns限制死循环，超了直接失败退出。输出是 JSON，流水线可以直接解析。
如果任务根本不需要写文件，更稳妥的方案是用plan模式而不是bypassPermissions。只读模式跑分析任务，连 deny 清单都可以省很多。我建议按照自己的实际任务性质来选择：纯分析用 plan，真正需要写文件再考虑 bypass，而且永远配上--disallowedTools兜底。
5. 安全网设计：哪些权限不该放开，以及 hooks 门禁兜底
5.1 永远不要轻易放进 allow 的命令
权限配置不是放开越多越好。下面这些操作，要么后果不可逆，要么作用面超出当前仓库，建议一律 deny 或 ask：
| 操作类型 | 示例 | 建议 |
|---|---|---|
| 强制删除 | rm -rf /、git clean -fd | deny |
| 远端强制推送 | git push --force | deny 或 ask |
| 下载后直接执行 | curl ... | bash | deny |
| 有全局副作用的命令 | 数据库迁移、发布上线、包发布 | ask 或人工执行 |
| 敏感文件读取 | ~/.ssh/*、.env、*.pem | deny 或 ask |
这些命令的共同点是“后果很难撤销”或者“影响面不可控”。权限配置的本意不是限制模型能力，而是把可逆操作和不可逆操作分开处理。能用 diff 解决的放开，不能用 git 救回来的就必须守一道闸。
5.2 hooks 钩子：比配置文件更硬的防线
如果团队里要落地“绝对禁止”的清单，光靠 settings 还不够。因为配置文件可以被个人修改，手一滑就放开了。Claude Code 的 hooks 机制能提供更硬的一层拦截：在工具调用之前触发自定义脚本，脚本以非零状态退出，工具调用就会被中断。
以拦截危险 Bash 命令为例，.claude/settings.json里加这样一段：
{ "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "bash ./hooks/guard-bash.sh" } ] } ] } }然后创建hooks/guard-bash.sh：
#!/usr/bin/env bash input=$(cat) if echo "$input" | grep -q '"command":"rm -rf'; then echo "禁止执行强制删除命令" >&2 exit 2 fi if echo "$input" | grep -q 'curl.*|.*bash'; then echo "禁止管道执行下载内容" >&2 exit 2 fi exit 0记得给脚本加执行权限：chmod +x hooks/guard-bash.sh。
这个脚本会收到一个包含工具名和参数的 JSON。我用 grep 是为了示例尽量短，实际项目建议用jq解析字段，判断更精确。hooks 事件不止PreToolUse，还有PostToolUse、Notification等，按需选择即可。它的核心价值是：即使你在 settings 里放开了某项权限，危险操作依然能被脚本拦死，这层防线比“依赖模型自觉”可靠得多。
5.3 兜底习惯：先存档，再放开
最后分享几个我实际操作中的兜底习惯。
让 Claude Code 大改代码之前，先看一眼git status，确认工作区是干净的。如果不干净，先提交一个“改动前存档点”，或者用git stash把未提交内容暂存起来。改动面很大的重构，我建议用git worktree add ../temp-claude开一个临时工作树，让模型在里面随便折腾，出了问题直接删目录，完全不碰主工作区。
更极端的需求，比如让模型自己安装依赖、修改系统配置，那就放进容器或虚拟机里，权限全部放开也不用担心。无人值守的自动化任务，只让它作用于受控目录，不要让它自动扫描整个家目录或者访问/tmp之外的位置。模型能力再强，不该碰的内容从一开始就别让它碰到，这才是配置权限的最终目标。
我在这套配置上跑了一段时间之后，最大的感受是：日常开发已经基本告别确认弹窗，但危险操作仍然被牢牢挡住。可逆的操作放开，不可逆的操作必问，这个原则比任何“信任模型”的说法都管用。如果你也在折腾权限配置，建议从acceptEdits加一份简单的 allow 清单开始，跑几天再慢慢补充 deny 规则，一步到位直接上跳过权限参数只会把风险窗口拉大。
