最后更新于 2026 年 8 月 15 日；本文已核对官方安全、沙箱、权限、代理和开发容器资料，以及 Claude Code 官方安全公告和 Wiz 的原始研究。
Claude Code 沙箱配置 2026 的直接结论是：可信自有仓库可以在收紧权限后的本机沙箱中运行；来源不明、需要安装依赖、调用 MCP 或开放网络的仓库，不要直接接触主力 Mac 的 SSH 密钥和云凭据，应改用专用虚拟机或独立云端 Mac。
这不是单纯打开一个确认弹窗就能完成的安全配置。文件系统、网络出口和权限绕过必须同时受限；如果凭据已经挂载进执行环境，沙箱并不能把它们“变得不可读取”。
这篇文章适合 3 类人：
- 需要用 Claude Code 审查开源项目、陌生 Pull Request 或第三方脚本的开发者；
- 允许 AI Agent 执行测试、安装依赖和调用 MCP 工具的团队负责人；
- 准备部署专用云端 Mac 作为长任务执行节点的环境管理员。
启动前先判断：仓库内容可能比命令本身更早影响环境
典型失败路径是：开发者克隆一个外部 GitHub 仓库，进入目录后直接运行 claude，随后按照提示批准读取配置、执行安装脚本或访问网络。问题在于，风险不只来自 Claude Code 生成的 Shell 命令，还可能来自仓库中的项目配置、Hooks、MCP 声明、符号链接、依赖安装脚本，以及外部工具返回的恶意内容。
官方安全公告曾披露：受影响版本在加载恶意仓库配置时，可能在信任提示出现前使用攻击者控制的 ANTHROPIC_BASE_URL 发起请求，并导致 API 密钥泄露；该公告将受影响范围列为低于 v2.0.65，修复版本为 v2.0.65。因此，启动前首先应完成更新，而不是先打开仓库再等待提示保护环境。可参考官方安全公告原文。
⚠️ 注意： 信任弹窗属于交互层审批，不等于操作系统隔离。Anthropic 的工程复盘也明确区分了人工审批、沙箱、虚拟机和网络出口控制；任何一层都不能替代另外几层。可阅读Anthropic 关于 Agent containment 的工程复盘。
启动前可先完成以下检查：
- ✅ 确认仓库来源、维护者、最近提交和依赖锁文件是否合理；
- ✅ 检查
.claude/、项目级settings.json、启动脚本和 Hooks； - ✅ 检查
mcp.json或其他 MCP 声明，确认是否会启动本地进程或访问外部 API； - ✅ 使用
find、readlink或同类只读命令检查符号链接是否指向工作目录之外； - ✅ 检查
package.json、pyproject.toml、Makefile、安装脚本和容器配置； - ✅ 搜索异常的域名、下载地址、远程 Shell、编码后的脚本和可疑环境变量。
第一次审查应停留在只读阶段。若仓库要求执行 npm install、pip install、构建脚本或测试服务，风险等级就不再是“阅读代码”，而是“允许第三方代码进入执行环境”。
首次运行前清空凭据，再选择 Claude Code 沙箱配置 2026
在主力 Mac 上，最容易被忽略的隐性成本是凭据暴露。SSH 私钥、云平台访问密钥、代码签名材料、生产环境变量、浏览器会话和本地密码管理器代理，一旦能被执行环境读取，后续即使限制了某些写入路径，也无法消除已经发生的读取风险。
建议把主机状态调整为“无长期凭据”：
- 从
~/.ssh移除不必要的私钥，或改用一次性、低权限的测试密钥； - 不把云平台长期访问密钥写入
.env、Shell 配置或容器挂载目录； - 不在陌生仓库中使用生产证书、App 签名材料和发布令牌；
- 检查
SSH_AUTH_SOCK、云厂商环境变量和自定义 API 代理地址； - 不将宿主机的整个 Home 目录挂载进容器或远程执行节点；
- 任务需要 Git 推送时，优先使用范围受限、可撤销的临时凭据。
沙箱能替 SSH 私钥兜底吗？
只有在 SSH 私钥没有进入沙箱、SSH Agent 不允许被执行环境调用，并且网络出口也受到限制时，保护才具有实际意义。macOS Seatbelt 可以约束 Bash 及其子进程的文件和网络访问，但它不会替开发者自动撤销已经挂载的密钥；官方工程文章强调，凭据如果从未进入沙箱，代理即使被诱导也更难直接窃取。
首次启动可以先使用计划模式：
claude --permission-mode plan
计划模式适合让 Claude Code 阅读项目、列出修改方案和指出潜在风险，但不应被误认为完整隔离。它减少了执行动作，却没有把仓库放进独立操作系统边界。
首次信任时按权限层级放行，而不是一次性全开
Claude Code 的权限配置应遵循“先观察、再允许、最后收窄”的顺序。官方 CLI 文档列出了 plan、默认审批、acceptEdits 和 bypassPermissions 等模式；其中绕过权限模式只适合已经具备独立隔离边界的环境。可查看官方 CLI 参数说明。
推荐的首次信任策略如下：
- 计划模式： 只阅读和分析，不执行修改与命令；
- 默认模式： 每次遇到新的 Shell、文件写入或外部工具调用时人工确认；
- 接受编辑模式： 仅用于已经确认来源的仓库，且仍保留命令与网络审批；
- 绕过权限模式： 只有在无长期凭据、无生产网络、独立容器或虚拟机中考虑。
权限规则应使用三种动作表达边界：
| 动作 | 适合放行的对象 | 不适合放行的对象 |
|---|---|---|
deny |
SSH 目录、云凭据目录、生产配置、危险命令、未批准的 MCP | 不能只拒绝文件名而忽略真实路径 |
ask |
安装依赖、Shell、网络访问、文件写入、Git 推送 | 不应因为提示频繁就改成全局允许 |
allow |
git status、git diff、只读搜索、指定测试命令 |
不应直接允许任意 Shell 或整个网络 |
在规则冲突时，应让拒绝规则优先于允许规则，并通过 /permissions 检查当前会话实际生效的配置。权限规则可以约束 Claude Code 的行为，但不能防止操作系统漏洞、恶意依赖或已获准命令产生外部副作用。
陌生 GitHub 仓库适合直接交给 Claude Code 吗？
如果只是隔离目录中的只读检查，风险相对可控；如果仓库会自动加载配置、启动 Hooks、安装依赖或访问外部服务，就不能把“打开”视为无害动作。更稳妥的做法是先在无凭据环境中静态检查，再进入沙箱执行阶段。
第一次执行时同时限制文件系统与网络出口
Anthropic 的沙箱机制使用 macOS Seatbelt 等操作系统级能力，对 Bash 及其子进程提供文件系统和网络边界；官方介绍称，沙箱默认允许工作区内写入、限制工作区外写入，并默认阻断网络，再通过白名单放行必要域名。官方内部数据显示，启用沙箱后权限提示数量减少 84%，但这属于产品方的内部使用结果，不等于任何仓库都获得同等安全效果。可参考Anthropic 的沙箱机制说明。
配置时应把三类边界分开处理：
- 工作目录边界： 只允许仓库目录和临时构建目录写入，拒绝访问 SSH、云凭据、签名材料和生产配置；
- 网络出口边界： 只放行模型 API、必要的软件包源和明确批准的 Git 服务，其他域名默认拒绝；
- 权限绕过边界： 禁止把
--dangerously-skip-permissions当作兼容性修复手段，遇到命令失败应先缩小命令、修复路径或迁移到隔离环境。
如果团队使用代理或出口网关，应将 Claude Code 的流量纳入统一审计。官方代理文档列出了模型 API、统计服务和错误报告服务等网络要求，并提醒不要把代理密码硬编码在脚本中；可参考官方代理配置文档。
| 执行需求 | 本机 Seatbelt 沙箱 | Dev Container | 专用虚拟机或云端 Mac |
|---|---|---|---|
| 只读审查代码 | ✅ 合适 | ✅ 合适 | 可用但成本更高 |
| 安装第三方依赖 | ⚠️ 需无凭据环境 | ✅ 较合适 | ✅ 更适合长期任务 |
| 需要访问多个外部域名 | ⚠️ 必须白名单 | ⚠️ 需配置出口 | ✅ 可单独配置网络 |
| 需要 Xcode、签名或 macOS 工具链 | ✅ 本机可用 | 受宿主环境限制 | ✅ 更容易单独交付 |
| 允许长时间自动执行 | 不建议直接使用 | 需审查挂载和网络 | ✅ 适合专用节点 |
| 任务结束后彻底清理 | 依赖人工检查 | 可销毁容器 | ✅ 可销毁并重建实例 |
容器是否等于完整隔离？
不能。Dev Container 通常能把文件系统、依赖和部分网络配置与主机分开，但是否存在特权模式、宿主目录挂载、Docker Socket、SSH Agent 转发、共享网络和可写凭据，取决于具体配置。它是额外隔离层，不是自动成立的安全边界；开发容器应被视为降低污染范围的工具，而不是对所有威胁的保证。
按风险条件选择本机、容器还是独立 Mac
可用下面的条件分支快速决策：
- 若仓库属于团队自有项目、依赖已锁定、无需访问生产系统，选择“本机沙箱 + 默认审批”；
- 若仓库来源可信但需要固定依赖和可重复构建，选择“Dev Container + 无凭据挂载 + 网络白名单”；
- 若仓库来源不明、包含安装脚本、需要调用 MCP 或需要开放网络，回退到“专用虚拟机或独立云端 Mac”；
- 若任务会持续运行、需要安装多个工具链或可能修改系统配置，不要使用主力 Mac；
- 若需要 Xcode、macOS 专属构建工具或签名流程，优先选择可单独销毁的 Mac 执行节点；
- 若无法确认文件、网络和凭据边界，停止执行，不要用更宽松的权限规则换取“先跑起来”。
对于团队管理员，建议把执行节点设计成一次性环境：任务开始时注入短期凭据，任务完成后导出必要产物，随后销毁实例，而不是长期保留已经运行过陌生脚本的系统。需要了解云端 Mac 使用方式时，可先查看 RUVCLOUD 的 Mac 远程使用入口，再结合任务时长和工具链要求决定是否创建临时节点。
任务结束后检查外部副作用，再决定是否销毁环境
代码回滚和安全清理不是一回事。git reset 可以撤销工作区变化，却不能撤销已经上传的密钥、已经创建的云资源、已经修改的远程账户，或已经发送到第三方服务的数据。
结束时按以下顺序验收：
- ✅ 查看
git diff、未跟踪文件和新增隐藏目录； - ✅ 检查 Shell 配置、启动项、Hooks 和计划任务是否被修改；
- ✅ 检查
~/.ssh/authorized_keys、SSH 配置和 Agent 使用记录； - ✅ 查看云平台、软件包源和外部 API 的访问日志；
- ✅ 检查异常域名、异常上传、未知进程和新增凭据文件；
- ✅ 撤销临时令牌、测试密钥和 MCP 服务授权；
- ✅ 对一次性环境优先销毁重建，而不是继续沿用原实例。
如何把 Claude Code 的文件与网络边界收紧？
文件访问应通过工作目录、额外目录和拒绝规则共同约束；网络访问则应通过沙箱白名单、企业代理或出口防火墙控制。不要只在提示词中要求“不要访问敏感文件”，也不要只依赖权限弹窗，因为提示词和人工审批都无法替代操作系统级拒绝规则。
如果检查结果发现密钥曾被读取、网络边界曾被放宽、符号链接曾指向工作区外，或容器曾挂载 Docker Socket，最稳妥的判断是立即废弃环境并重建。Wiz 于 2026 年 7 月披露的 GhostApproval 研究讨论了符号链接和审批界面未充分展示真实目标的问题；该研究属于第三方披露，不能扩写为所有版本都必然可被利用。可阅读Wiz 的原始安全研究。
当前主力 Mac 与独立云端 Mac，差别在爆炸半径
把陌生仓库直接放在主力 Mac 上，优点是启动快、工具齐全，但缺点也很明确：SSH 和云凭据容易残留，个人文件与开发目录边界复杂，长任务可能持续修改环境，而且一次误批准可能影响日常工作系统。Dev Container 能缓解依赖污染，却仍可能因目录挂载、网络共享或凭据转发留下跨边界路径。
对于来源不明、需要安装依赖或需要长时间运行的任务，独立云端 Mac 的价值不是“天然安全”，而是更容易做到无长期凭据、单独网络策略、任务结束销毁和环境重建。完成仓库风险分级后，可以参考 RUVCLOUD 的远程 Mac 方案页面，先确认文件访问、网络出口、凭据注入和销毁方式是否满足任务要求，再决定是否创建临时执行节点。