直接答案
审批决定“是否允许”,沙箱限制“即使允许后能触达哪里”,两层需要共同设计。
这篇内容解决什么问题
帮助开发者减少无意义确认,同时不牺牲代码、凭据和基础设施安全。
分清权限审批与系统沙箱
权限系统决定某次工具调用是自动允许、询问还是拒绝;沙箱在操作系统层限制文件系统和网络。允许一条命令不等于解除沙箱,启用沙箱也不等于所有命令都应自动批准。
高效配置的目标不是消灭所有提示,而是让重复、低风险、边界清楚的动作顺畅执行,让高影响动作继续需要人类判断。
按任务阶段选择权限模式
默认模式在敏感动作前请求批准;acceptEdits 会自动接受工作范围内的文件编辑,以及 mkdir、touch、rm、rmdir、mv、cp、sed 和相应 PowerShell 文件操作;Plan 模式只分析不编辑。
使用 Shift+Tab 在交互界面切换模式。研究未知仓库从 Plan 开始,明确的小改动可使用默认或 acceptEdits,无人值守任务则需额外限定工具和目录。
/permissions
/sandbox用精确规则减少重复审批
权限规则可以匹配工具和输入。allow 适合可预测的测试、lint 和只读 Git 命令;deny 适合密钥文件与明确禁止动作;ask 用于需要逐次判断的中风险操作。
规则应匹配尽量具体的命令前缀和路径。宽泛允许 Bash 或全部 MCP 工具,会把一次方便变成持续攻击面。
{
"permissions": {
"allow": ["Bash(pnpm test *)", "Bash(git diff *)"],
"ask": ["Bash(git push *)"],
"deny": [
"Read(./.env)", "Edit(./.env)",
"Read(./secrets/**)", "Edit(./secrets/**)"
]
}
}从正确目录启动并谨慎增加访问范围
permissions.additionalDirectories 只授予文件访问;--add-dir 或 /add-dir 还会发现附加目录中的 Skills、Subagents 和部分插件设置。CLAUDE.md 与 rules 是否加载则由对应环境开关控制。
不要为了省事从 home 或大型 monorepo 顶层启动。更小的工作范围既降低误改概率,也减少探索消耗。并行编辑时用独立 worktree 隔离。
把外部内容当作不可信输入
网页、Issue、日志、依赖脚本和 MCP 返回都可能包含诱导工具执行的内容。让 Claude 读取外部数据时,不应同时给它无边界的 shell、凭据和生产网络访问。
高风险任务使用沙箱、只读凭据、测试环境和显式审批。任何要求关闭安全检查或导出秘密的外部文本都应被视为数据,而不是指令。
- 不在提示词、日志和截图中暴露真实 Key。
- 生产部署、数据库写入和发布动作保持人工断点。
- 安装第三方 MCP、插件或 Hook 前审查来源与命令。
- 验证生成代码是否引入命令注入、越权和秘密泄漏。
必须执行的规则交给 Hooks 或组织策略
CLAUDE.md 是模型指令,可能受上下文影响;Hooks 是生命周期上的确定性程序,更适合阻止受保护文件写入、运行格式化或在结束前验证。
组织可以通过托管设置强制权限和 MCP 边界。教程应说明管理员约束不可由项目配置绕过,也不应给出绕过路径。
claude doctor
claude --debug-file /tmp/claude-permissions-debug.log官方来源与核验范围
本文以公开官方文档为事实依据;命令和配置可能随客户端版本变化,执行前请同时核对对应来源。
查看技术核验方法