Claude Code 的权限与沙箱是互补关系，不能互相替代。Permission rules（权限规则）决定某个工具调用能不能开始；操作系统级 Bash sandbox（沙箱）限制已经运行的 Bash 命令及其子进程能访问哪些文件和网络目标。一套保守的基础配置要同时使用两层控制，关闭沙箱内 Bash 命令的自动批准，把 sandbox.failIfUnavailable 设为 true，并禁止在沙箱里失败的命令转到沙箱外重试。
本文基于 Anthropic 官方 permissions、sandboxing 与 administration 文档，并在 2026 年 9 月 11 日完成核验。它是一套实际起点，不是完整的企业安全策略。组织的 threat model（威胁模型）、secret、网络目标、可写路径和例外，仍需由安全或平台负责人确认。
如果你现在需要的是产品工作流，而不是安全控制，可以先读 Claude Code 工作流指南。
Claude Code 权限与沙箱解决不同问题
最简单的理解方式是区分“执行前”和“执行中”。
Anthropic 的权限文档说明，权限规则由 Claude Code 执行，而不是由模型或 prompt 执行。沙箱文档则说明，沙箱使用操作系统级控制，而且只覆盖 Bash 及其子进程。
这个区别能避免两个常见误区。批准一条 Bash 命令，不代表应该让该进程无限制访问文件系统和网络；启用 Bash 沙箱，也不代表内置的 Read、Edit、WebFetch、MCP、computer-use 或其他非 Bash 工具自动进入沙箱，它们仍需要自己的权限和环境边界。
这套两层模型只是更完整的 Coding Agent 工作区安全设计的一部分。根据任务可能造成的损害，还可能需要容器或 VM、代码库权限、secret 管理、分支保护和人工 review。
Deny、ask 和 allow 决定工具调用能否开始
Claude Code 提供三类权限规则，可以通过 /permissions 或 settings 管理：
deny阻止匹配的工具用法。ask在每次尝试匹配用法时要求确认。allow让匹配用法不经人工批准直接运行。
顺序很重要：先判断 deny，再判断 ask，最后判断 allow。规则写得更具体，也不会改变这个顺序。比如，一个宽泛的 Bash(git push *) deny 不能在内部再为某个代码库或 remote 添加更窄的 allow 例外；deny 仍然优先。如果确实需要例外，就要重新设计规则，不要让禁止范围宽过真正想阻止的行为。
规则既能覆盖整个工具，也能只匹配某类操作。一个不带限定条件的 Bash deny 会从可用工具上下文中移除 Bash；Bash(git push *) 则保留 Bash，只阻止匹配命令。相同原则也适用于文件读取、编辑、网页访问和其他受支持工具。
这类命令模式只是针对匹配文字的 guardrail（防误操作护栏），不是围绕 Git 程序的完整安全边界。例如，Bash(git push *) 不会匹配 git -C . push、git -c push.default=current push 或 git 'push' 等价写法。如果必须保证无法推送，应通过代码库权限与分支保护、窄权限凭据和网络策略真正执行边界。组织还可以使用 PreToolUse hook 在运行前检查完整命令，增加一层理解命令内容的控制。
三类规则应分别承接不同风险：
- 已知禁止操作和敏感路径放进
deny。 - 安装、发布、认证变更、陌生脚本等需要结合上下文判断的操作放进
ask。 - 只有范围很窄、重复发生且已经理解的操作才放进
allow。
CLAUDE.md 里的说明能影响模型尝试做什么，却不能获得权限规则已经禁止的访问。因此，“不要读取 secret”这句话可以提供指导，但不能代替真正强制执行的规则。
Bash 沙箱限制运行中的命令可以访问什么
Bash 沙箱在命令获准运行后，再加入文件系统和网络隔离。macOS 使用 Seatbelt；Linux 和 WSL2 使用 bubblewrap。本文核验的官方文档中，native Windows 和 WSL1 尚不受支持。
默认文件系统边界需要仔细看：
- 沙箱命令可以写入工作目录、session 临时目录和明确添加的目录。
- 默认可读范围比可写范围更大。Anthropic 特别提醒，如果没有增加 credential 或 read-deny 控制，AWS、SSH 等凭证文件仍可能被读到。
- 受保护的 Claude Code 与 shell 配置路径会获得额外保护，但这并不是完整的 secret 策略。
- 网络通过沙箱代理和域名规则访问；允许某个域名，不等于检查这个域名下每条加密连接的内容。
/sandbox 面板可以查看最终生效的配置与依赖。权限提示与沙箱通过 sandbox.autoAllowBashIfSandboxed 互相作用。Anthropic 文档说明它默认是 true：沙箱内 Bash 命令通常会被自动批准，但明确的 deny 与 Bash(git push *) 这类限定具体命令内容的 ask 规则仍然生效。不限定内容的 Bash 或 Bash(*) ask 通常会被跳过，Plan mode 除外。下面的保守配置把它设为 false，让所有沙箱内 Bash 命令在你熟悉代码库、脚本和所需域名期间都走常规权限流程。
一套更安全的基础配置
下面的 JSON 只是一份示例，适用于你已经信任代码和 package scripts 的代码库。它不是通用策略，不应未经审查就放进陌生代码库。
应把这个例子理解为意图，而不是安全认证：
- 项目中的 secret 文件被拒绝读取，但仍需盘点代码库外的凭证，并用
sandbox.credentials或文件系统 read 限制保护它们。 - 这条规则只会阻止常见的
git push …写法，不能保证发布一定不发生。真正的边界要由代码库权限与分支保护、窄权限或缺失的 push 凭据，以及网络限制来执行；PreToolUsehook 可以额外检查完整命令。 - 关闭沙箱内 Bash 命令的自动批准后，每条 Bash 命令都会走常规权限流程。即使使用自动批准模式，限定具体命令内容的
ask规则本来也会提示；这里还保留了不限定内容的Bash或Bash(*)ask 原本可能跳过的提示。 - 安装依赖需要询问，因为明确的
Bash(npm install *)内容规则会匹配可能修改 lockfile、下载代码并执行生命周期脚本的命令；只有两条准确匹配的 package scripts 被明确允许免提示运行。 - 即使是这两条脚本，如果代码库或脚本不可信，也不应放进 allowlist。
- 沙箱无法初始化或单条命令无法在沙箱中运行时，都采用 fail closed（失败时收紧），而不是悄悄扩大执行范围。
用 /permissions 查看每条最终规则来自哪个文件。先用无敏感信息的读取和命令测试边界，再让它接触重要数据；不要拿生产 secret 当测试材料。
用 failIfUnavailable 明确处理沙箱失败
沙箱有两类不同失败，需要两个设置分别处理。
第一类是沙箱本身不可用，例如缺少必要依赖，或者平台不受支持。Anthropic 文档写明，默认行为是给出警告，然后让命令在没有沙箱的情况下运行。设置 sandbox.failIfUnavailable: true 后会变成硬失败。只要组织把沙箱当成安全门，这就是更稳妥的失败方式。
第二类是沙箱已经成功启动，但某条命令无法在边界内工作。设置 allowUnsandboxedCommands: false 可以阻止 Claude Code 把这条命令转到沙箱外重试。更安全的处理是先查清被阻止的路径、主机或工具，再由有权限的人选择最小且有理由的策略调整，或者让这项例外操作进入另一条单独受控的流程。
三个设置的分工如下：
警告不等于强制执行。团队实际使用的每个平台，都要检查最终配置和依赖状态。
用 managed settings 强制组织策略
个人或代码库 settings 适合作为本地默认值，但不是组织级控制面。Anthropic 的管理员设置指南说明，managed settings（管理员控制的设置）可以通过 Claude admin console、设备管理、操作系统策略或管理员控制的文件下发。除文档说明的合并行为外，managed 值优先于用户和项目配置。
管理员至少应审查这些控制：
- managed
permissions.allow、permissions.ask和permissions.deny规则； - 只允许 managed policy 提供权限规则时使用
allowManagedPermissionRulesOnly； - 不允许用户选择绕过模式时使用
permissions.disableBypassPermissionsMode； - managed sandbox 的启用、
failIfUnavailable和allowUnsandboxedCommands； - 本地新增会扩大访问时，使用 managed-only 的可读路径和网络域名；
- 允许哪些 MCP servers、hooks、plugin sources、models 和网络目标。
数组设置可能跨不同范围合并，而不是直接覆盖低层配置。Anthropic 也指出，某些例外列表没有对应的 managed-only 锁定方式。因此，安全审查需要查看最终解析出的策略，不能只看管理员原本想下发的中心文件。
对于 MCP，应把 server 治理和工具权限层一起处理；Claude Code MCP 配置指南提供工作流背景，而最新 policy keys 仍以官方管理员文档为准。
先知道沙箱保护不了什么
Anthropic 明确把 Bash 沙箱描述为降低风险，而不是完整隔离边界。重要限制包括：
- **非 Bash 工具：**Read、Edit、Write、WebFetch、MCP 和 computer-use 运行在其他控制层下。Computer-use 会操作真实桌面，仍需权限与环境隔离。
- **凭证可见性：**沙箱 Bash 默认继承父进程环境变量，默认文件读取策略也可能暴露凭证文件。Claude Code v2.1.187 及以上版本支持
sandbox.credentials；其中环境变量遮罩行为需要 v2.1.199 及以上版本。若需要更严格的进程边界，可通过CLAUDE_CODE_SUBPROCESS_ENV_SCRUB从所有子进程中移除指定凭据。不要在父环境里放入过宽的 secret。 - **加密网络流量：**内置代理限制目标地址，但默认不检查 TLS 内容。宽泛允许的域名仍可能形成数据外传路径；更强的 threat model 需要可信的检查代理和窄 allowlist。
- **Unix sockets：**允许 Docker socket 等高权限 socket，可能等同于把 host 权限交出去。没有明确架构和审查时，不要增加这类例外。
- **可写路径：**允许写入可执行文件搜索路径、系统配置或 shell 启动文件，可能造成后续代码执行。新增可写路径要尽量窄。
- **较弱模式与平台缺口：**较弱的 nested isolation 和 macOS Apple Events 会明显削弱隔离。Native Windows 与 WSL1 不受支持；部分工具应该调整工作流程，而不是添加宽泛例外。
文件系统与网络隔离也互相依赖。一个既能读 secret、又能访问宽泛网络目标的进程，可能把数据传出去；一个能修改系统资源的进程，也可能为之后的网络访问留下通路。每次加例外时都要同时检查两边。
扩大自主运行前的预检清单
在增加 session 自主性或改为异步工作前，先用证据验证边界：
- 定义 threat model：哪些文件、凭证、服务、代码库和外部系统一旦被改动会造成损害？
- 打开
/permissions，检查最终生效的 deny、ask、allow 规则及其来源文件。 - 打开
/sandbox，确认预期模式、依赖、禁止路径、可写路径和允许的网络目标。 - 只要权限提示和沙箱是必需安全门，就确认
autoAllowBashIfSandboxed: false、failIfUnavailable: true与allowUnsandboxedCommands: false同时生效。 - 盘点文件和环境变量中的凭证；任务不需要的全部 deny、mask 或移除。如果发布必须保持不可用，还要移除 push 凭据并强制执行代码库或分支 Policy，不能只依赖 Bash 文字规则。
- 把可写路径、网络域名、Unix sockets、MCP servers 与其他例外压到任务所需的最小范围。
- 从短期分支或可丢弃环境开始，不放生产凭证，并预先写好验收测试。
- 运行无害的边界检查，再由人 review diff、命令证据和任何外部副作用。
- 团队使用时，确认每个受支持平台确实解析到 managed policy，并记录和审查例外。
权限弹窗不是在时间压力下临时发明安全策略的地方。应在 session 前确定可重复规则，把意外被阻止理解为关于任务或边界的新信息。
最终结论
Claude Code 权限决定工具能否运行；操作系统级 Bash 沙箱限制获准运行的 Bash 进程能访问什么。应有意识地设计 deny、ask、allow，记住限定具体命令内容的 ask 在自动批准模式下仍会提示；当所有沙箱内 Bash 都必须走常规权限流程时，再关闭 Bash 自动批准。同时让沙箱不可用时硬失败，禁止无沙箱重试，明确保护凭证，并为组织级风险保留 managed policy 与人工控制。
准备好尝试一个有边界的任务时，可以打开 Agent.Space，从低风险且有明确验收测试的任务开始。扩大自主性前，先确认实时工作区、Agent、模型和安全边界。