权限策略与可信工作区

01区分意图与权限

提示词和 CLAUDE.md 描述希望怎样工作；权限规则决定工具调用是否能执行。团队需要把两者配合起来，尤其是修改文件、执行 Shell、调用外部服务时。

官方权限规则按 deny、ask、allow 的顺序判断。一个宽泛 deny 不会因为存在更具体的 allow 就自动失效。

02根据任务选择模式

先探索仓库时可以使用 plan；准备开发时按项目需要选择默认审批或允许编辑。切换模式之前明确它会允许哪些类型的动作。

• Plan：适合理解代码、定位问题和评估方案。
• 默认审批：便于逐项检查工具调用范围。
• acceptEdits：降低常见文件编辑的交互成本。
• 自动化需要预先定义许可范围、工作目录和运行边界。

03建立权限评审清单

新增 MCP、Hook 或 Shell 规则时，检查会访问的目录、网络目标和身份凭证。审批规则应尽量写到实际需要的命令或服务，不使用覆盖一切的允许项。

• 打开陌生仓库后，先阅读其脚本与项目指令。
• 检查持久化权限是否超过当前任务所需范围。
• 关键限制应配合隔离环境、文件权限和服务端鉴权。

/permissions

04一个范围明确的构建允许项

下例只演示允许执行项目已有 npm run build 的规则结构，应合并到合适的 settings.json 作用域，而不是覆盖整份配置。配置前先审查 package.json 中 build 脚本实际会做什么。

允许一个脚本意味着信任它执行的逻辑。脚本内部仍能调用其他程序，因此此规则不等于沙箱；需要更强边界时配合容器、文件权限和服务端权限。

{"permissions":{"allow":["Bash(npm run build)"]}}

05怎样验证规则真的符合预期

先在测试项目验证允许的命令，再检查一个未授权的相近命令是否仍走正常审批。规则变更完成后记录配置位置，避免同事误以为只在当前会话生效。

• 命令匹配中的空格、参数与通配符会改变范围。
• deny、ask、allow 的优先级不能靠“更具体”自动覆盖。
• 检查当前版本官方语法，出现无效设置告警时先修复再继续。