Claude Code 安全配置指南：减少弹窗，不减安全

核心问题：如何在不用 --dangerously-skip-permissions（DSP）和 Docker/VM 的前提下，让 Claude Code 少弹窗、多干活？

一句话答案：启用内置 Sandbox + autoAllowBashIfSandboxed，用 OS 级隔离替代逐条审批。

为什么需要这份指南

Claude Code 默认每次文件写入和 bash 命令都要手动确认。Anthropic 数据显示用户批准了 93% 的请求¹，绝大多数确认是走过场。审批疲劳后反而不认真看，直接点 approve。

常见「解法」是开 DSP，但这跳过所有安全检查²，等于给 Claude 完整 shell 权限。需要更好的方案。

四层安全机制速览

推荐组合：Layer 1 + Layer 2，全部确定性、零开销。Layer 3 可选叠加（需 Team plan³）。

关键机制详解

Sandbox：减少弹窗的核心

Sandbox 用 OS 原生隔离（macOS Seatbelt / Linux bubblewrap⁴）限制 bash 子进程的文件和网络访问。实现细节可参考 Anthropic 的工程博客⁵。

核心开关 autoAllowBashIfSandboxed⁶：启用后，沙箱内的 bash 命令自动放行，不弹窗。

{
  "sandbox": {
    "enabled": true,                    // 启用 OS 级沙箱（默认 false，需手动开启或用 /sandbox 命令）
    "autoAllowBashIfSandboxed": true,   // 沙箱内命令自动放行（默认 true）
    "excludedCommands": ["docker", "git push", "git fetch", "git pull", "git clone"],
    "filesystem": {
      "allowWrite": ["."],              // 白名单：未列出的路径默认不可写
      "denyRead": ["~/.ssh", "~/.aws", "~/.gnupg"]
    },
    "network": {
      "allowedDomains": ["github.com", "registry.npmjs.org"],
      "allowUnixSockets": ["/var/run/docker.sock"],  // 允许 Unix socket
      "allowLocalBinding": true         // 允许本地端口绑定（开发服务器需要）
    }
  }
}

Sandbox filesystem 有四个键⁶：

• allowWrite — 可写路径白名单，默认只含 ["."]（当前工作目录）
• denyWrite — 禁止写入的路径黑名单
• denyRead — 禁止读取的路径黑名单
• allowRead — 在 denyRead 区域内重新允许读取，优先级高于 denyRead

Sandbox 管辖范围——注意它只管 Bash⁶：

Permission Rules：硬性边界

通过 allow/ask/deny 三个列表做模式匹配。评估顺序：deny → ask → allow，deny 始终优先²。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",    // 允许所有 npm run 子命令
      "Bash(git commit *)"  // 允许 git commit
    ],
    "deny": [
      "Bash(sudo *)",             // 禁止提权
      "Bash(git push --force*)",  // 禁止强推
      "Read(~/.ssh/**)",          // 禁止读 SSH 密钥（仅阻止 Claude 内置 Read 工具）
      "Read(~/.aws/**)"           // bash 子进程需用 sandbox denyRead 阻止
    ]
  }
}

注意：Read/Edit deny 规则只阻止 Claude 内置工具，不阻止 Bash 子进程。比如 deny: ["Read(./.env)"] 不会阻止 cat .env。要 OS 级阻止，得用 sandbox 的 denyRead。

Auto Mode（可选）

独立的 Sonnet 4.6 分类器在每次操作前审核安全性，两层防御（input-layer 探测 + output-layer 分类），误报率仅 0.4%¹。Simon Willison 的评价⁷：

“I still want my coding agents to run in a robust sandbox by default, one that restricts file access and network connections in a deterministic way. I trust those a whole lot more than prompt-based protections like this new auto mode.”

目前需要 Team plan（Enterprise 和 API 即将支持），且要求 Sonnet 4.6 或 Opus 4.6 模型，管理员需先在后台启用³。属于 research preview 阶段。结论：加分项，不是必需项。

Permission Modes 速查

CLI 中按 Shift+Tab 切换³：

常见踩坑

坑 1：SSH 协议被沙箱网络拦截

沙箱网络通过 HTTP/SOCKS 代理服务器控制出站流量⁶。SSH 连接是原始 TCP，不走代理，会被 OS 级沙箱直接拦截。因此 git push（SSH 协议）在沙箱内必定失败⁸。

修复：将 git 远程操作加入 excludedCommands。本地 git 操作（add、commit）不涉及网络，仍在沙箱内自动放行。

坑 2：excludedCommands 中的命令仍需手动确认

excludedCommands 让命令跳过沙箱，但同时也失去了 autoAllowBashIfSandboxed 的自动放行。这些命令会回到常规权限确认流程——除非你在 permissions.allow 中额外添加对应规则。

坑 3：默认配置下的隐式写入保护

沙箱默认 allowWrite 只覆盖 ["."]（当前工作目录），因此 ~/.bashrc、~/.zshrc 等路径默认不可写。虽然技术上可以通过 allowWrite 添加这些路径，但官方强烈不建议——允许写入 shell 配置文件或 $PATH 中的可执行文件目录可能导致跨安全上下文的代码执行⁶。

其他已知限制

• docker、watchman 不兼容沙箱，需加入 excludedCommands
• 网络过滤基于域名，存在 domain fronting 风险（攻击者利用 CDN 共享域名绕过域名白名单）
• Sandbox 只管 Bash 工具，不管 Read/Write/WebSearch/WebFetch/MCP 等⁶

配置作用域

优先级：Managed > CLI 参数 > Local > Project > User⁹。deny 在任何层级生效后，其他层级无法覆盖。Sandbox 路径跨 scope 合并（merge），不替换。

最佳实践：全局底线放 User 级（~/.claude/settings.json），项目级只放差异配置。比如你的全局已经配好了 sandbox + deny 规则，项目级只需要加特定工具的放行规则：

// .claude/settings.json（项目级，只放 diff）
{
  "permissions": {
    "allow": [
      "mcp__telegram__*"
    ]
  }
}

推荐方案：分层安全模型

全局底线（~/.claude/settings.json）

{
  "permissions": {
    "allow": [
      "Glob", "Grep", "Read", "ToolSearch", "WebFetch", "WebSearch"
    ],
    "deny": [
      "Bash(sudo *)", "Bash(mkfs *)", "Bash(dd *)",
      "Bash(wget *|bash*)", "Bash(curl *|bash*)",
      "Bash(git push --force*)", "Bash(git push *--force*)",
      "Bash(git reset --hard*)",
      "Read(~/.ssh/**)", "Read(~/.gnupg/**)", "Read(~/.aws/**)",
      "Read(~/.config/gh/**)", "Read(~/.docker/config.json)",
      "Edit(~/.bashrc)", "Edit(~/.zshrc)", "Edit(~/.ssh/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["docker", "git push", "git fetch", "git pull", "git clone"],
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.gnupg", "~/.aws", "~/.config/gh", "~/.docker/config.json"],
      "allowWrite": ["."]
    }
  }
}

按项目覆盖

Level 1 — 信任区（个人项目）：全局配置已够用，项目级无需额外配置。

Level 2 — 标准区（团队项目）：收紧网络 + 保护生产分支。

{
  "sandbox": {
    "network": {
      "allowedDomains": ["github.com", "codeup.aliyun.com", "*.npmjs.org", "pypi.org"]
    }
  },
  "permissions": {
    "deny": ["Bash(git push * main)", "Bash(git push * master)", "Bash(npm publish *)"]
  }
}

Level 3 — 隔离区（审查外部代码）：只读 + 无网络。

{
  "sandbox": {
    "autoAllowBashIfSandboxed": false,
    "filesystem": {
      "denyRead": ["~"],
      "allowWrite": []
    },
    "network": { "allowedDomains": [] }
  },
  "permissions": { "defaultMode": "plan" }
}

各等级对比

方案对比总结

附录：一键审查你的配置

把以下 prompt 复制到 Claude Code 中执行，即可自动审查并优化你的安全配置。

请审查我的 Claude Code 安全配置。

## 参考资料

1. 先用 WebFetch 读取这篇指南，理解 Sandbox + Permission Rules 的分层安全模型：
   https://niracler.com/2026-03-26-claude-code-security-config/
2. 再用 context7（resolve-library-id 搜 "claude code"，然后 query-docs）查官方最新文档，
   确认指南中的配置项在当前版本是否仍然适用、是否有新增配置项。

## 执行步骤

1. **收集配置**：读取 `~/.claude/settings.json`（全局）以及所有项目的 `.claude/settings.json` 和 `.claude/settings.local.json`
2. **分析摩擦点**：扫描 `~/.claude/projects/` 下各项目的 session 历史，找出被反复手动确认的高频命令和 bypassPermissions 使用频率
3. **对照指南审查**：按指南中的检查清单（Sandbox、Permission Rules、配置作用域）逐项对照当前配置
4. **输出改动方案**：

| # | 文件 | 现状 | 建议 | 原因 |
|---|------|------|------|------|
| 1 | ... | ... | ... | （引用指南或官方文档中的具体依据） |

以及各项目的摩擦分析表：

| 项目 | 主要摩擦来源 | 建议 allow 规则 |
|------|-------------|----------------|
| ... | ... | ... |

5. **给出修改后的完整 JSON**（可直接复制使用），并列出需要用户手动处理的事项

脚注