Claude Code Approval 与 Sandbox 指南 | 日常安全使用的实战设置

很多团队以为“开了 approval 就安全了”。现实往往相反。只要弹窗太多，人就会开始机械地点“同意”。如果 allow 放得太宽，AI 又可能把本来应该人工确认的动作直接做掉。

这篇文章写给已经知道 Claude Code 很好用、但还没有把日常边界设计清楚的人。它不是重复 完整权限指南，而是回答一个更实战的问题：

哪些动作应该自动执行，哪些动作应该 ask，哪些动作应该直接 deny？

如果你想先看整体思路，可以搭配 Harness Engineering 完整指南、安全失败案例 与 危险提示词模式 一起阅读。

approval 不等于安全

真正可靠的日常配置，至少要有三层：

控制层	作用	典型对象
permission 规则	定义 allow / ask / deny 的边界	secrets、破坏性命令、deploy
approval 流程	在不可逆副作用前停下来	git push、发布、发邮件
sandbox	缩小 shell 能接触的范围	build、验证、探索性脚本

官方文档建议始终以一次信息为准：permissions、settings、hooks。permissions 页面解释了读取型工具、shell 命令与文件修改在审批上的差异；settings 页面讲的是作用域与优先级；hooks 页面则说明如何在工具前后插入确定性的检查。

最重要的结论并不是“把 ask 开得更多”。真正重要的是：可回滚的动作尽量快，不可回滚的动作故意慢。

每天用时，先这样分就够了

操作	建议	原因
读文件、搜索、看 diff	allow	风险低，价值高
build、test、lint、analytics	allow	不能拖慢迭代
在分支内修改代码	ask 或会话级 allow	看仓库成熟度
git push、deploy、publish、send	ask	会产生外部副作用
读取 .env、rm -rf、git reset --hard	deny	事故半径太大
对第三方 API 做写操作	ask	会影响真实系统

很多人最犹豫的是“编辑代码到底算不算危险”。答案不是绝对的。测试完善、回滚容易的个人 sandbox 仓库，可以适当放宽。生产相关、测试薄弱的仓库，则应该保守。关键不在于“改不改”，而在于改完之后拿什么验证。

一个可直接参考的 .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

这份配置表达的是三件事：

1. 阅读和验证动作尽量快。
2. 会影响外部世界的动作必须停下来确认。
3. 明显危险的动作直接禁掉。

如果你的环境不支持 sandbox，就把更多有副作用的动作放进 ask。当前官方 sandbox 设置页面主要描述的是 macOS、Linux、WSL2 下的 Bash sandbox，因此在没有等价边界的环境里，更应该依赖明确的 allow / ask / deny。

再加一层 hooks，坏习惯会少很多

permissions 决定“能不能做”，hooks 决定“做之前和做之后强制跑什么”。这两层一起用，才会真正改变团队习惯。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

Windows 仓库可以把 grep 换成 findstr 或小型 Node.js 脚本。重点不是具体命令，而是：

• 在提交前拦住 secrets
• 在 deploy 前强制 build
• 在编辑后自动跑确定性的验证

三个典型工作流

1. 多语言内容站

内容站的真正流程不是“写完文章”就结束，而是：

1. 读取最近 7 天 analytics
2. 选择紧邻高流量簇的主题
3. 写新文章
4. 补齐多语言版本
5. build
6. deploy
7. 打开公开 URL
8. 用 Playwright 验证手机宽度

今天我们就在 ClaudeCodeLab 上把规则改严了：每次 run 必须发布一篇新文章，再推进一个既有任务，最后用 Playwright 检查新文章在所有语言 URL 上都真的 live。

2. 应用仓库

在应用仓库里，Claude Code 很适合自动处理：

• 搜索代码
• 阅读差异
• 分支内重构
• build / test 循环

但下面这些应该保留在 ask：

• push 到共享分支
• 执行 DB migration
• 调用生产 admin API
• 变更基础设施和 deploy 状态

3. 外联与后台自动化

AI 很擅长调研和起草，不适合在无人确认时直接发送。

可以自动的：

• 读取公开网站
• 分类 lead
• 生成样例页面
• 起草邮件

应该 ask 的：

• 发送邮件
• 改写正式 CRM / 表格记录
• 发布页面

三种最常见的失败

失败 1：什么都 ask

第一天看起来很安全，两周后就会变成机械点确认。这样反而更危险，因为人会以为自己“已经审过了”。

失败 2：把 --dangerously-skip-permissions 变成日常

官方文档的语境一直很清楚：这类跳过只适合严格受控的自动化。日常对话里常态化使用，本质上是在拿副作用做赌博。

失败 3：把 build 成功当成上线成功

本地 build 通过，不代表公开页面已更新。真实世界里的常见问题是：URL 还是旧内容、某个语言没发布、移动端 CTA 崩了。approval 和 sandbox 都替代不了公开 URL 验证。

一套真的能落地的检查顺序

1. 先把 secrets 和破坏命令放进 deny
2. 把 push / deploy / publish / send 放进 ask
3. 把读取和验证命令放进 allow
4. 至少加一个阻断 hook 和一个验证 hook
5. 所有 deploy 都要求检查公开 URL
6. 每周回看 approval，只有在验证体系足够成熟后才把动作提升到 allow

我们今天实际改了什么

我们把 ClaudeCodeLab 的 daily automation 从“今天随便推进一项工作”改成了更严格的规则：

• 每次都必须发布一篇新文章
• 还必须推进一项既有任务
• Playwright 必须检查手机显示
• 新文章的所有语言 URL 都要在生产环境返回 HTTP 200

真正提升安全性的，不是再加一句“请小心”，而是把操作规则写得足够具体。

下一步

先从 免费 cheatsheet 开始，把日常命令和安全习惯放在手边。如果你想直接拿到可复制的 settings、hooks、CLAUDE.md 与 CI/CD 配置，可以继续看 产品页。如果你需要一起设计团队 rollout、review 边界与安全自动化流程，可以走 咨询页面。