一个项目每天都要跑同一条测试命令，可以把这条命令的授权固定下来。先确认脚本做什么，再配置精确 allow，最后用同一命令验收。 下面以已有 npm run lint 的项目为例。
第一步：建立授权前的基线
打开 package.json，找到 lint 对应脚本，确认它是否只做检查，是否还会改文件或连接外部服务。再让 Claude Code 在项目目录运行一次，记下确认框展示的完整命令。
如果项目使用 pnpm 或其他工具，将示例替换为项目实际命令。测试名称相同，不代表不同仓库中的脚本内容相同。
第二步：配置这一项操作
输入 /permissions，查看当前规则和来源。个人项目设置可保存在 .claude/settings.local.json。例如把这一项合并到已有 permissions 中：
{
"permissions": {
"allow": ["Bash(npm run lint)"]
}
}
保留文件中其他已有键和规则。 使用编辑器检查 JSON 语法，再回到 /permissions 确认规则被识别。
若已存在 ask 或 deny 匹配，先查其用途。Claude Code 按 deny、ask、allow 的顺序判断，新增 allow 无法跳过更高优先级规则。
第三步：用可观察结果验收
让 Claude 再执行与基线完全相同的命令。记录是否免确认执行、命令退出状态和检查输出。当前版本的权限修改从下一次工具调用开始生效。
可保存下面的简短记录：
项目：示例前端仓库
已审阅脚本：package.json 中的 lint
规则：Bash(npm run lint)
配置来源：项目本地设置
复测命令：npm run lint
确认框：填写实际结果
检查结果：填写实际退出状态和报错
免确认运行与测试通过是两个结果，分别记录。测试失败时，根据输出修复具体问题；授权成功本身不改变测试结果。
后续扩展保持逐项可解释
确实需要添加第二条测试命令时，用同样步骤检查。远端推送、发布、修改权限等操作独立决定。acceptEdits 模式会自动接受工作范围内的文件编辑和部分文件系统命令，选择前应了解实际范围。
团队共享规则可由项目负责人审阅后管理；个人免确认需求先保留在本地设置，避免未经讨论改变所有人的工作方式。
常见问题
Q: 项目只有 pnpm lint，可以照抄 npm 示例吗？
A: 使用项目实际命令，授权规则应匹配真正执行的命令文本。
Q: 配置保存后怎么确认被识别？
A: 在 /permissions 检查规则和来源，再运行同一命令观察确认行为。
Q: allow 存在却仍然弹窗怎么查？
A: 核对完整命令、附加参数，以及更高优先级的 ask 和 deny 规则。
Q: lint 脚本更新后需要重查吗？
A: 需要。规则仍匹配同一命令名，实际执行内容已经可能改变。
Q: 免确认执行成功就能算配置完成吗？
A: 还要记录测试本身是否通过；权限验收和项目测试各自有结果。
Q: 本地规则能直接给全团队使用吗？
A: 先由团队审阅授权范围，再放到适当的共享配置；本地设置适合个人项目需求。