用熟之后，第一个想改的就是权限：它问得太频繁了。
这一节讲怎么少问，以及少问的代价是什么。
六种模式，Shift + Tab 循环切换
| 模式 | 界面上叫 | 行为 |
|---|---|---|
default |
Manual | 每类工具第一次用时问你 |
acceptEdits |
Accept Edits | 自动接受文件编辑，以及 mkdir mv cp 这类常见文件操作 |
plan |
Plan | 只读不写：它可以看、可以跑只读命令，但不改你的文件 |
auto |
Auto | 自动批准，但后台跑安全检查核对动作是否符合你的要求 |
dontAsk |
— | 自动拒绝没有预先授权过的工具 |
bypassPermissions |
— | 全部跳过 |
当前模式会显示在输入框的边框和提示区，一眼能看到。
实际上你只需要用三个
| 场景 | 用哪个 |
|---|---|
| 日常 | default |
| 一件已经想清楚、要连续改很多文件的活 | acceptEdits |
| 还没想清楚，先让它看一遍出方案 | plan |
plan 值得特别推荐。 一件事比较大的时候，先切到 plan 让它读材料、给方案，确认之后再动手——方案阶段发现理解偏差，成本是零。
「以后别问了」的有效期
这是这一节最重要的一条，而且几乎没人知道。
选了「Yes, don’t ask again」之后，能记多久，取决于你批准的是什么：
| 你批准的是 | 记多久 |
|---|---|
| shell 命令 | 永久，而且写进磁盘文件 |
| 文件修改 | 只到这个会话结束，不写盘 |
命令类的授权会落盘
批准一条 shell 命令并选「以后别问了」，这条规则会被写进你这个代码仓库根目录下的 .claude/settings.local.json。
从此这个仓库里所有的会话都适用——包括子目录里启动的、以后新开的。
这意味着什么：你随手批准的那条命令，不只是这一次。三个月后你早忘了，它还在生效。
想看自己批准过什么，用
/permissions。 建议偶尔翻一次。
文件修改的授权不落盘
批准编辑文件并选「以后别问了」，只在当前会话有效，关掉就没了。
这是一个刻意的设计：改文件的影响是具体的、一次性的；而一条命令可以在任何时候对任何东西执行。
三条规则：允许、询问、拒绝
用 /permissions 管理，也可以直接写进配置文件。
| 类型 | 效果 |
|---|---|
| allow | 不问，直接用 |
| ask | 每次都问 |
| deny | 直接挡住 |
求值顺序：deny → ask → allow
第一条匹配上的说了算，规则写得多具体不影响顺序。
这一条有个反直觉的后果：
一条宽泛的 deny 规则，挡得住一条更具体的 allow。
你写了
deny: Bash(aws *)，又写了allow: Bash(aws s3 ls)——后者不生效，因为 deny 先匹配上了。deny 规则不支持例外。 要留口子，就把 deny 写窄一点。
一个实用的例子
假设你不想让它碰任何 .env 文件（那类文件里常放密钥）：
{
"permissions": {
"deny": ["Read(.env)", "Read(**/*.env)"]
}
}
这条 deny 会同时挡住读和改——包括通过 cat、head、sed 这类命令去读。
但它挡不住间接的读取。 如果它跑了一个脚本，而那个脚本自己打开了文件，权限规则看不见这件事。要在操作系统层面挡死，得开沙箱。
关于 bypassPermissions
它跳过几乎所有提示，包括对 .git、.claude、.vscode 这类配置目录的写入。
官方的措辞是：只在容器或虚拟机这类隔离环境里用。
不建议在你自己日常干活的机器上开这个。
它剩下的保护只有一条熔断：对根目录和主目录的删除（
rm -rf /这类）仍然会问你。 除此之外没有别的拦截。
如果你担心自己或者别人误开，可以在配置里把它锁死：
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
这个开关在任何一层配置里都生效——也就是说，你可以自己给自己上锁。
配置文件的优先级
从高到低：
| 层级 | |
|---|---|
| 1 | 组织统一下发的配置 —— 谁都盖不过，包括命令行参数 |
| 2 | 命令行参数 |
| 3 | 项目本地配置 .claude/settings.local.json |
| 4 | 项目共享配置 .claude/settings.json |
| 5 | 用户配置 ~/.claude/settings.json |
有一条横跨所有层级的规则：
任何一层拒绝了，其他层都无法允许。
用户配置里 allow、项目配置里 deny —— deny 赢。 反过来也一样。
一个可能会遇到的确认框
在一个新项目里第一次启动时，可能会弹出一个信任对话框，问你信不信任这个文件夹。
原因是：项目配置文件里的 allow 规则只有在你接受信任之后才生效。
这是防一类具体的攻击：你从网上下载了一个项目，它的配置文件里预先写好了一堆 allow 规则。不接受信任，那些 allow 就不生效。
deny 和 ask 不受影响——它们只做限制，所以一直生效。
不确定的项目就选「不信任」。 你仍然能用，只是会多问你几次。
一句总结
提示词和
CLAUDE.md决定它想做什么，权限规则决定它能做什么。这两件事互不替代。要真正挡住一件事，写规则，不要写嘱咐。
本节事实查证日期：2026-08-05。 依据：官方 Configure permissions。