什么是权限模式，为何一次性设定
权限模式让你一次性决定 Claude Code 在不必每次征询你的情况下可以运行什么。Claude Code 做的是实际工作——读写文件、执行终端命令、安装依赖包——如果每个动作前都问一句“可以这么做吗”，任务越长，你就越要守在批准提示旁。权限模式预先设定这条界线，让 Claude 在安全范围内不再询问、直接推进。
设置很简单。在 Claude Code 中按住 shift 再按 tab，模式会按顺序切换。manual、acceptEdits、plan、auto 这四种在此循环中轮换，当前处于哪一种会显示在底部的状态栏（status bar）。其余两种 dontAsk 和 bypassPermissions 用于无人值守运行或隔离环境等特殊场景。
关键在于“让模式匹配任务”。前期你想逐行查看每处改动时，多询问的模式更安全；方向已定、只剩重复性工作时，少询问的模式更快。下面按“自动放行的程度”依次说明六种模式。
| 模式 | 自动做什么 | 何时使用 |
|---|---|---|
| manual | 只读；其余一切每次都问 | 逐个动作确认、谨慎推进时 |
| acceptEdits | 读取 + 文件编辑 + 常见文件系统命令 | 反复修改代码、事后一次性审阅时 |
| plan | 只读、调研、提方案；不编辑 | 执行前先拿到方案时 |
| auto | 执行一切，由分类器预先拦截危险动作 | 放手不管的默认选择 |
| dontAsk | 只允许预批准工具，其余静默自动拒绝 | CI、夜间批处理等无人批准时 |
| bypassPermissions | 跳过所有检查 | 仅在隔离的容器或虚拟机中 |
每次都问的一侧——manual 与 plan
manual 是最保守的模式。Claude Code 只对读取不加询问，其余动作——编辑文件、执行命令——都要在运行前得到你的确认。当你想逐一查看并批准每处改动，或是在小心处理陌生代码库时，它很合适。
plan（计划模式）同样只读，但目的不同。plan 会调研代码，提出“要改什么、怎么改”的方案，却不真正编辑文件。在启动大任务前，让 Claude 先通读代码并给出执行计划，你读过之后再把握方向。计划越周密，执行时偏离的余地越小。
把审阅推后的一侧——acceptEdits
acceptEdits 对读取、文件编辑以及常用的文件系统类终端命令都不再询问。Claude 改代码时你不必每次去按批准键，流程得以持续，你在结果出来后一次性审阅。
因此 acceptEdits 契合“先快速迭代、审阅放到后面”的工作方式，在打磨方向已定的代码、需要多轮修改时尤其高效。只是由于改动是事后确认的，前提是你之后必须回过头去核对改了什么。
放手不管的默认选择——auto 模式与分类器
想要放手交办时，首先要考虑的模式是 auto。在 auto 模式下，Claude 不询问就执行动作，但在前端有一个独立的分类器模型（classifier）在每个动作执行前进行审查。它只拦下被判定为危险的动作，其余日常工作照常放行。也就是“全部自动”，但只挑出危险的加以叫停。
分类器拦截的是“超出你请求、把事情做大”的动作。例如生产环境部署与数据库迁移、强制推送（force push）、把下载的代码直接管道输入 shell 执行、把敏感数据发往外部端点、删除会话所需的文件等。相反放行的是日常工作：项目内的本地编辑、按锁文件（lockfile）安装依赖、只读请求，以及推送到你自己的分支。
auto 位于 shift+tab 循环的末位，便于开启，状态栏可确认当前是否为 auto。之所以称它为“放手不管的默认选择”，是因为即便没有人一直守着批准，分类器也会守住危险的边界。
分类器的盲区与 stop hook
auto 的分类器有明确的局限。它守护的是意图，却不检查代码是否真的正确运行。比如你让 Claude 重构认证逻辑，结果写出的是坏掉的认证代码，分类器仍会放行——因为“坏掉”并不等于“危险”。
因此 auto 的正确用法是与运行测试的 stop hook 搭配。stop hook 是 Claude 完成一轮工作时自动运行的检查，把测试运行接进去，auto 守住“想做什么（意图）”的同时，hook 确认“代码是否真的能跑（正确性）”。意图归分类器，正确性归 hook。
auto 的护栏仍在演进，拦截与放行的清单会不断变化。真正使用 auto 时，最好在官方文档查看当前的拦截与放行清单。
{
"hooks": {
"Stop": [
{ "hooks": [ { "type": "command", "command": "npm test" } ] }
]
}
}无人值守流水线用 dontAsk，隔离环境用 bypassPermissions
dontAsk 面向没有人能批准的自动化场景。它只允许你预先批准的工具，凡不在清单上的动作都不提示、直接自动拒绝。在 CI 流水线、定时任务、通宵批处理这类身边无人的场景里，它让流水线继续前进，而不是卡在一个无人点击的批准提示上。
bypassPermissions 跳过所有检查。它等同于 Claude Code 的 dangerously-skip-permissions 设置——没有分类器、没有批准，什么都照跑。正因如此危险，只应在隔离的容器或虚拟机（VM）中运行。它不是可以在真实工作环境里常开的模式。
结论——让模式匹配任务
权限模式有多种，但日常使用的几种都在 shift+tab 循环之内。放手不管的默认选择是 auto，其安全由两层守护：动作运行前，分类器检查意图；一轮结束后，stop hook 检查代码是否真的能跑。
身边无人批准的无人值守流水线交给 dontAsk，而跳过一切检查的 bypassPermissions 只属于隔离的容器与虚拟机。最终归为一条：放手到什么程度要按任务而非胆量来定，并选择与之匹配的权限模式。