2026 Cursor Agent 团队沙箱怎么配？Apple Container 分角色方案

截至 2026 年 9 月 2 日，Apple Container 的官方实现是在 Apple Silicon Mac 上为 Linux 容器分别启动轻量级虚拟机，而不是把 macOS 应用装进一个“Mac 容器”里。Apple Containerization 官方说明 因此，本周不要把一份宽松沙箱配置复制给全员：普通开发优先使用 Cursor 原生沙箱，依赖安装和高风险脚本再套一层 Apple Container，签名、生产凭据与发布操作保留人工审批，并迁移到独立 Mac 环境。

这篇文章适合：

• 研发负责人：需要确定 Cursor Agent 团队执行基线和例外审批规则。
• 仓库维护者与构建工程师：需要保留依赖安装、测试和缓存能力，同时限制宿主文件访问。
• 发布与安全负责人：需要把签名、密钥和生产操作从普通 Agent 会话中拆出去。

先按角色分权，而不是按工具统一放权

一个常见的组织失败案例是：平台负责人为了减少确认弹窗，配置了一份允许写入工作区、访问包管理器、调用构建脚本和使用发布工具的沙箱文件，然后让所有 Cursor Agent 用户直接复制。结果普通开发者不仅可以改代码，还继承了构建与发布权限；真正的问题不是某条命令危险，而是职责边界被配置文件抹平了。

Cursor 当前的本地执行安全由两层组成：

1. Run Modes 决定哪些工具调用自动执行、哪些调用需要审批。
2. sandbox.json 决定沙箱命令能访问哪些路径、临时目录和网络域名。

Cursor 官方文档说明，macOS 本地沙箱使用 Seatbelt 机制，工作区默认可读写，但 .git/config、.git/hooks、.vscode、.cursor 中部分配置文件等路径仍受保护；网络访问则可通过允许列表和拒绝列表控制。Cursor Run Modes 文档 sandbox.json 字段说明

这意味着“工作区可写”不等于“数据安全”。如果工作区中存在未提交的密钥、内部脚本、部署配置或软链接，Agent 仍可能在允许范围内读取并改写高价值内容；如果网络策略过宽，依赖安装、脚本下载和远程接口访问也会形成额外风险。

个人开发者的最低基线应是：

• 日常代码生成、格式化、静态检查和单元测试：使用 Auto-review 或带沙箱的 Allowlist。
• 工作区：只允许当前项目目录写入，重要改动先提交到可恢复分支，或复制到临时副本。
• 网络：只开放实际使用的代码托管、包管理器和测试服务域名。
• 删除、批量重命名、修改工作区外文件、调用云端管理命令：默认要求人工确认。
• 不使用 Run Everything 作为团队默认值；它会取消本地 Agent 的主要审批边界。

Cursor 还提供文件删除保护和外部文件保护，但这些保护属于执行链上的额外控制，不能替代分支、备份和权限设计。Cursor Terminal 与保护机制说明

功能开发成员使用项目级配置，不能共用一份 sandbox.json

功能开发成员的任务通常是修改当前仓库、运行测试和安装项目依赖，最适合采用“个人基础配置 + 仓库策略”的组合，而不是给每个人一份完全相同的全局权限。

Cursor 支持两个主要配置位置：

• ~/.cursor/sandbox.json：用户级配置，适用于该用户打开的所有工作区。
• <workspace>/.cursor/sandbox.json：项目级配置，只作用于当前仓库。

两者同时存在时，项目级设置优先；团队管理员策略和 Cursor 内置保护还会继续叠加，不能被本地文件削弱。路径通常是合并，网络拒绝规则也会继续叠加，而更严格的默认策略优先。Cursor sandbox.json 合并规则

可以把普通功能开发成员的项目策略收口为下面这种结构：

{
  "type": "workspace_readwrite",
  "additionalReadonlyPaths": [
    "/Users/Shared/team-readonly"
  ],
  "additionalReadwritePaths": [
    "./.agent-cache"
  ],
  "disableTmpWrite": false,
  "enableSharedBuildCache": false,
  "networkPolicy": {
    "default": "deny",
    "allow": [
      "github.com",
      "registry.npmjs.org",
      "pypi.org"
    ],
    "deny": [
      "169.254.169.254"
    ]
  }
}

这份示例只表达权限结构，不包含真实域名、令牌或生产地址。实际使用时，应根据项目锁文件和构建工具补充依赖源，避免直接放开全部网络。

允许资源：

• 当前仓库工作区；
• 明确列出的只读共享目录；
• 项目专用缓存目录；
• 完成依赖安装所需的精确域名。

禁止资源：

• 整个主目录，例如 /Users/某用户；
• ~/.ssh、云厂商凭据目录、通用密钥目录；
• 生产配置目录；
• 未经审查的共享工作区；
• 通过软链接间接指向宿主敏感路径的目录。

为什么不能整体挂入主目录？因为目录权限一旦扩大，Agent 看到的就不再只是代码，而可能包括 shell 配置、历史命令、云端凭据路径和其他项目。只读挂载也不是绝对安全边界：只读只能限制写入，不能阻止敏感信息被读取后通过允许的网络发送出去。

仓库维护者的高风险脚本应进入 Apple Container

仓库维护者经常需要运行迁移脚本、代码生成器、批量重写工具和第三方安装脚本。这些任务的风险高于普通单元测试，因为脚本可能扫描仓库外路径、执行系统级安装、访问网络，或根据环境变量改变行为。

此时，Cursor 原生沙箱仍然适合做审批入口，但不应成为唯一隔离层。更稳妥的流程是：先创建临时仓库副本，再让 Agent 在 Apple Container 内完成高风险任务，只把结果目录和必要输入挂载进去。

Apple Container 的关键边界是：每个 Linux 容器运行在轻量级虚拟机中，容器内是 Linux 用户空间；它适合隔离 Linux 构建、脚本和依赖环境，不是 macOS 应用容器。Apple WWDC25 Containerization 介绍 Containerization 架构说明

一个不包含破坏性命令的任务脚本示例：

#!/bin/zsh
set -euo pipefail

SOURCE_REPO="${1:?需要传入临时仓库副本路径}"
OUTPUT_DIR="${2:?需要传入输出目录}"

mkdir -p "$OUTPUT_DIR"

container run --rm \
  --mount "type=bind,source=${SOURCE_REPO},target=/workspace" \
  --mount "type=bind,source=${OUTPUT_DIR},target=/output" \
  --network default \
  docker.io/library/ubuntu:24.04 \
  bash -lc '
    cd /workspace
    printf "container=%s\n" "$HOSTNAME"
    test -f package.json || true
    mkdir -p /output/report
    printf "任务完成时间：%s\n" "$(date -u)" > /output/report/run.txt
  '

生产环境不能直接照搬这段命令。平台负责人还应根据任务决定是否关闭网络、是否使用独立网络、是否把输入目录改成只读，以及是否使用 --rm 清理临时容器。Apple Container 官方文档支持绑定挂载、只读挂载和临时内存文件系统；其中 readonly 或 ro 可把挂载目录设为只读。Apple Container 挂载与卷文档

需要再套一层 Apple Container 的判断条件

• 若任务只修改当前仓库，并且脚本来源已审核，选 Cursor 原生沙箱。
• 若任务要执行第三方安装脚本、批量代码生成或未知迁移逻辑，回退到临时仓库副本 + Apple Container。
• 若任务需要访问宿主机钥匙串、Xcode、模拟器或 macOS 原生工具链，不要强行放进 Apple Container，改走受控 Mac 环境。
• 若任务涉及真实生产凭据、签名证书或发布令牌，禁止交给普通 Agent 会话，升级到人工审批的独立环境。
• 若团队无法验证挂载目录、网络出口和回滚责任人，先暂停自动执行，不能用“容器隔离”替代验收。

构建与测试工程师的例外权限必须有期限

构建工程师比普通功能开发成员需要更多资源：包管理器、镜像仓库、测试服务、编译缓存和可能的临时数据库都可能成为必需项。但“构建失败”不是放开全部宿主目录和全部网络的理由。

建议把例外拆成四类记录：

Cursor 的 enableSharedBuildCache 可以让部分构建工具使用共享缓存，但共享缓存会扩大跨项目影响面；如果一个构建脚本污染缓存，其他项目可能继承错误结果。因此，只有构建工程师或专门的构建组才适合申请该例外，普通开发成员仍应使用项目级缓存。Cursor sandbox.json 配置参考

无网络或缓存失效时，团队应提前定义降级路径：

1. 优先使用锁定版本和本地缓存；
2. 缓存不存在时，只允许访问已登记的依赖域名；
3. 依赖源不可用时，输出失败报告，不自动切换到未知镜像；
4. 测试服务不可用时运行离线单元测试，禁止把测试地址改成生产地址；
5. 构建产物必须在隔离环境完成校验后，才能进入发布流程。

Apple Container 的网络能力与 macOS 版本、运行时配置和网络模式有关。官方文档说明，macOS 26 支持创建相互隔离的容器网络；但网络隔离应以团队自己的出口测试为准，不能仅凭网络名称判断已经阻断外连。Apple Container 网络配置文档

发布与签名人员必须保留独立 Mac 边界

代码准备、构建验证、代码签名和发布是四类不同动作，不应因为前两类可以自动化，就把后两类一起交给 Cursor Agent。

可以交给隔离环境的工作：

• 代码格式化与静态检查；
• 依赖解析和可重复构建；
• 测试包生成；
• 产物哈希计算；
• 发布清单和变更记录生成。

必须保留人工确认的工作：

• 访问签名证书和钥匙串；
• 使用发布令牌；
• 上传 App、插件或服务端产物；
• 修改生产环境配置；
• 执行不可逆的迁移和回滚操作。

Apple Container 运行的是 Linux 工作负载，因此不能直接替代依赖 macOS 原生签名工具、Xcode、模拟器和钥匙串的阶段。即便构建产物可以在 Linux 环境中准备，签名与发布仍应回到受控 Mac，并采用一次性凭据、人工确认和审计记录。

如果团队存在多人并行发布、敏感仓库或需要将员工日常设备与发布凭据拆开的需求，可以先阅读 JexMac 的团队 Mac 环境入口，再根据实际流程核对 Mac 环境帮助说明。这类独立环境的价值不是“让 Agent 获得更多权限”，而是把高风险权限从个人电脑上移走。

平台负责人用这张矩阵做最终审批

平台与安全负责人可以把角色策略收敛成四个等级：

• 开发角色： Cursor 原生沙箱；仅当前仓库可写，依赖网络按域名开放。
• 维护角色： Cursor 沙箱作为第一层，高风险脚本进入 Apple Container 临时副本。
• 构建角色： 允许受控缓存、镜像和测试服务，但每项例外必须记录路径、域名、负责人和期限。
• 发布角色： 代码准备与构建验证可隔离；签名、生产令牌和上传动作进入独立 Mac，并保留人工审批。

团队落地至少分 5 步：

1. 列出每个角色的任务，不从“谁需要 Cursor”这种工具视角开始。
2. 为每个任务标记输入、输出、网络、宿主路径和凭据需求。
3. 先配置 Cursor 原生 Run Modes，再添加最小化的 sandbox.json 例外。
4. 把第三方脚本、未知迁移和批量改写迁移到 Apple Container 临时副本。
5. 为构建缓存、依赖域名和测试服务设置到期时间，并安排回收人。
6. 用无网络、错误挂载、缓存污染和回滚场景做破坏性测试。
7. 每次模板升级都记录版本、变更原因、验证结果和回滚责任人。

最终判断可以简化为：

• 若任务不需要宿主机凭据、不访问仓库外目录，且失败可通过 Git 回退，选本地 Cursor 沙箱。
• 若任务需要 Linux 依赖隔离，或包含来源不完全可信的脚本，选 Cursor 沙箱 + Apple Container。
• 若任务需要 macOS 原生签名、模拟器、钥匙串或生产发布工具，选受控 Mac 环境。
• 若多人并行、凭据敏感且本地设备不应持有发布权限，选择独立云端 Mac，而不是继续扩大员工电脑的挂载范围。

从成本与风险的角度看，把所有权限塞进一份配置，短期少了审批弹窗，长期却会增加凭据泄露、错误发布、缓存污染和事故追责成本。对于只需要临时算力、隔离测试环境或多人并行执行的团队，租赁 JexMac 的 Mac 环境通常比在每台员工设备上长期维护一套高权限本地链路更容易验收；但如果团队长期运行稳定的重负载任务，或必须直接接触物理接口，自购 Mac 或本地专用设备仍可能更合适。建议先填写本文的角色权限矩阵，再结合 JexMac 的方案与周期信息 判断哪些高风险执行面值得迁出日常设备。