Bash 允许规则收紧：变量里的 * 会被警告，几种通配写法不再跳过确认
很多人为了少点几次「允许」，会在 settings 里给 Bash 加一堆允许规则。规则写得越宽，省下的确认越多，但也越容易放过本不该放过的命令。Claude Code 2.1.323 针对这类规则做了一轮收紧，值得每个配置过 permissions.allow 的人检查一下。
1. 变量值里带 * 的规则，启动时会警告
像下面这样的规则很常见：
json
"allow": ["Bash(PORT=* npm run dev)"]本意是「不管端口是多少，都允许跑 dev」。但 * 放在变量值里，能匹配的远不止一个数字——变量值里可以塞进各种内容。2.1.323 起，Claude Code 启动时会对这类规则给出警告，提醒你它比看上去宽得多。
更稳妥的做法是把端口固定下来，或者干脆把常用端口各写一条规则。
2. 贴着命令写的通配，不再跳过确认
Bash(ls*) 这种写法，* 直接贴在命令名后面。以前在某些情况下，它会让不该匹配的命令也跳过权限确认。这个问题已修复。
同时，以变量名开头的规则（例如 Bash(NODE_ENV*)）现在会改为询问，而不是直接放行——因为「以某个变量赋值开头」几乎可以接任何命令。
3. 合并写的 sudo 参数，不再绕过规则
sudo 的多个短参数可以合并写（比如把几个单字母参数连在一起）。以前，用这种合并写法的规则在某些情况下会跳过权限确认，现在也修好了。
4. rm 的危险删除判断不再看错目录
还有一个更隐蔽的问题：Bash 权限检查在判断 rm 是否危险时，有时会以错误的目录为准，导致在 bypass 权限模式或有 Bash 允许规则时，跳过了「危险删除」的提示。2.1.323 修复后，判断会基于命令实际执行的位置。
该怎么检查自己的配置
- 升级后启动一次 Claude Code，留意有没有关于允许规则的警告；
- 打开项目和用户级的
settings.json，搜一下Bash(规则里的*，尤其是贴着命令名或变量值的； - 能写具体就写具体：
Bash(npm run dev)比Bash(npm*)安全得多； - 涉及
sudo、rm的规则，尽量不要放进允许列表，宁可每次确认。
允许规则的目的是省掉重复确认，而不是把判断权全部交出去。这次收紧之后，宽规则「看起来安全、实际放行」的情况会少很多。