2026 Cursor Agent 怕误删文件？用 Apple Container 搭隔离沙箱

工作区突然少了文件，rm -rf 还可能碰到主目录。

最快解法：使用“可丢弃代码副本 + Apple Container 受限执行”的双层隔离，不要把安全性押在命令黑名单上。

这篇适合经常让 Cursor Agent 自动安装依赖、运行测试、生成代码或修改多文件项目的个人开发者，也适合需要统一 AI Agent 执行边界的研发负责人。如果你正在比较本地容器沙箱和远程隔离 Mac 环境，文末会给出回退条件。

先把 Cursor Agent 沙箱边界划清

Apple Container 面向 Apple Silicon Mac，运行的是 Linux 容器，并不是在容器里启动一套完整 macOS。Apple 官方仓库当前说明，它依赖 macOS 26 在虚拟化与网络方面的新能力；截至 2026 年 8 月 29 日，官方发布页显示最新稳定标签为 1.3.0，发布时间为 2026 年 8 月 24 日。(github.com)

这决定了它适合承载 Linux 工具链、依赖安装、代码生成、编译、单元测试和脚本执行。Xcode 图形界面、原生签名、模拟器、完整 macOS 构建流程，则应留在宿主机或单独的 Mac 开发环境中。

Cursor Agent 执行终端命令时，怎样避免误删宿主机文件？

不要让 Agent 直接打开唯一的原始仓库。先复制或临时克隆项目，再只把这份可回滚副本挂载到容器的 /workspace。容器退出后删除实例，宿主机原始仓库不参与执行链路。

Cursor 自带的审批、运行模式和 .cursorignore 仍然有价值，但它们是应用层护栏。Cursor 官方明确说明，运行模式属于尽力而为的防护，不是硬安全边界；.cursorignore 也不能阻止 Agent 通过终端或 MCP 工具访问被忽略文件。(prod.cursor.com)

因此，真正需要同时收紧的是：

• 文件边界：不挂载主目录、原始仓库、SSH 配置和云凭据。
• 写入边界：只允许写入可丢弃副本，根文件系统设为只读。
• 网络边界：不需要下载依赖时使用 --network none。
• 身份边界：容器内使用非 root 用户。
• 恢复边界：每次任务结束自动删除容器，并用 Git 差异检查结果。

准备阶段：可丢弃副本比命令黑名单更可靠

Apple Container 的官方要求是 Apple Silicon Mac，推荐运行 macOS 26；旧系统即使存在部分兼容路径，也不应作为正式安全基线。Apple 官方技术说明还指出，macOS 15 存在网络能力限制，例如不能使用完整的多网络管理命令，因此不适合照搬本文配置。(github.com)

先在宿主机执行：

uname -m
sw_vers -productVersion
container system status
container system version

你至少要确认：

• uname -m 返回 arm64；
• 系统为 macOS 26；
• container system status 能返回服务状态；
• 版本落在当前官方稳定发布范围内，而不是调试构建或过期二进制。

接下来创建工作副本。最简单的方式是使用临时克隆：

mkdir -p ~/agent-workspaces
git clone /path/to/original-repo ~/agent-workspaces/demo-sandbox
cd ~/agent-workspaces/demo-sandbox
git status --short

如果原仓库本身就在 Git 管理下，也可以使用 git worktree。重点不是命令形式，而是 Cursor 打开的目录必须与原始仓库分离。未提交文件先打包或复制一份，避免你误把“实验前状态”也覆盖掉。

建议在副本中放入一个诱饵文件：

mkdir -p .sandbox-canary
printf 'DO NOT DELETE\n' > .sandbox-canary/host-boundary-canary.txt

它不是安全机制，而是验收证据。后面可以让 Agent 或测试脚本尝试删除它，观察删除是否只发生在副本内部。

Apple Container 能否替代传统容器隔离 AI 编程助手？

它可以替代一部分本地 Linux 执行需求，但不能替代完整 macOS 虚拟机，也不能自动修复错误的宿主机挂载。Apple Container 的价值在于轻量 Linux 虚拟机、Apple Silicon 原生执行和较清晰的挂载控制；它不是 Cursor 的原生集成沙箱，也不是“只要启动就绝对安全”的开关。

第一小时：用 Apple Container 搭出受限执行层

先在项目外创建 Containerfile。Apple Container 使用 OCI 兼容镜像，并提供 container build 与 container run 命令；官方命令参考明确列出了 --read-only、--mount、--tmpfs、--network 和 --rm 等运行参数。(github.com)

FROM ubuntu:24.04

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       bash ca-certificates git curl build-essential python3 \
    && rm -rf /var/lib/apt/lists/* \
    && useradd --create-home --shell /bin/bash agent

WORKDIR /workspace
USER agent

CMD ["bash"]

这份文件做了三件事：

1. 提供常见 Linux 编译和脚本工具。
2. 删除 apt 缓存，减少镜像中的无用文件。
3. 使用 agent 非 root 用户启动任务。

构建镜像：

container system start
container build -t cursor-agent-sandbox:local -f Containerfile .

然后创建 sandbox-run.sh：

#!/bin/bash
set -Eeuo pipefail

IMAGE="cursor-agent-sandbox:local"
WORKSPACE="${1:?用法：$0 /绝对路径/可丢弃副本 [命令] [参数...]}"
shift

if [[ ! -d "$WORKSPACE" ]]; then
  echo "工作区不存在：$WORKSPACE" >&2
  exit 2
fi

WORKSPACE="$(cd "$WORKSPACE" && pwd)"

exec container run \
  --rm \
  --read-only \
  --network none \
  --mount "type=bind,source=${WORKSPACE},target=/workspace" \
  --tmpfs "/tmp:size=512M,mode=1777" \
  --tmpfs "/run:size=64M,mode=755" \
  "$IMAGE" \
  "$@"

赋予执行权限：

chmod +x sandbox-run.sh

运行编译或测试：

./sandbox-run.sh \
  "$HOME/agent-workspaces/demo-sandbox" \
  bash -lc 'cd /workspace && git status --short && ./run-tests.sh'

脚本中的安全作用如下：

• --rm：进程退出后删除容器实例，减少残留状态。
• --read-only：把容器根文件系统设为只读。
• --network none：不提供容器外网接口，只保留回环接口。
• --mount type=bind：只把指定副本映射到 /workspace。
• --tmpfs：让缓存和中间文件留在临时存储中，容器停止后消失。
• 非 root 用户：降低容器内命令获得额外权限的机会。

Apple Container 官方卷与挂载文档说明，tmpfs 数据在容器停止后会消失，readonly 可以用于绑定挂载；官方示例也使用了 512M 和 mode=1777 这类参数。(github.com)

⚠️ 可写挂载不是绝对隔离。 如果你把宿主机目录以可写方式挂载进去，容器内的 rm、覆盖和批量重命名仍可能修改那个目录。只读根文件系统保护不了主动暴露的可写宿主路径。

接入 Cursor Agent：允许重复动作，禁止高风险动作

现在让 Cursor 只打开：

~/agent-workspaces/demo-sandbox

不要同时打开包含原始仓库、个人脚本、SSH 配置或云平台配置的父目录。项目规则可以要求 Agent 使用包装脚本，例如：

- 安装依赖、编译、测试和代码生成必须通过 ./sandbox-run.sh 执行。
- 不得直接访问宿主机主目录。
- 不得读取 ~/.ssh、云凭据、钥匙串导出文件或生产环境变量。
- 删除文件、修改依赖锁文件、执行发布命令必须请求人工确认。
- 不得关闭 Git 检查，不得清理 .sandbox-canary。

可以自动放行的命令，应限制在低风险、可重复的范围：

• git status
• git diff
• 容器内的编译命令
• 容器内的单元测试
• 容器内的静态检查
• 读取构建日志

必须人工确认的类别包括：

• rm、批量删除和递归覆盖；
• sudo、修改系统服务和安装宿主机软件；
• 读取或注入凭据；
• 修改 SSH、钥匙串、云平台配置；
• git reset --hard、强制推送和发布；
• 关闭审批或改成所有命令自动执行。

这一步的原则是：Cursor 规则负责提醒和审批，Apple Container 负责实际文件、身份和网络边界。两者不要互相替代。

如何让 Cursor Agent 只能修改指定项目目录？

让它只打开可丢弃副本，并让所有需要执行的命令都经过 sandbox-run.sh。容器只挂载这个副本到 /workspace，不挂载 $HOME、原始仓库或父目录。.cursorignore 可以减少索引范围，但不能代替挂载权限。

关闭容器外部网络并隔离本机密钥，应怎样配置？

运行任务时使用 --network none，并且不要使用 --ssh、--env-file 或继承宿主机环境变量。需要下载依赖时，先在受控网络下构建缓存，再切换到无网络模式运行测试；不要为了方便长期开放网络。

密钥不应通过 ~/.ssh、钥匙串导出文件或整份环境变量注入。确需访问服务时，使用短期令牌、最小权限账号，并在任务结束后立即撤销。命令黑名单挡不住所有变体，挂载和网络边界才是主要防线。

破坏性验收：先证明越界失败，再交给 Agent

第一次运行不要直接处理重要项目。用诱饵文件、无害删除命令和敏感路径探测完成验收。

WORKSPACE="$HOME/agent-workspaces/demo-sandbox"

./sandbox-run.sh "$WORKSPACE" bash -lc '
  set -u
  echo "container workspace: $(pwd)"
  rm -f /workspace/.sandbox-canary/host-boundary-canary.txt
  test ! -e /workspace/.sandbox-canary/host-boundary-canary.txt
  test ! -e /root/.ssh
  test ! -e /workspace/does-not-exist
'

宿主机上检查：

test ! -e "$WORKSPACE/.sandbox-canary/host-boundary-canary.txt"
git -C "$WORKSPACE" status --short
container ls

验收至少覆盖以下结果：

• [ ] 原始仓库文件没有变化。
• [ ] 主目录中的诱饵文件没有变化。
• [ ] 容器内能修改可丢弃副本。
• [ ] --network none 下无法解析或访问外部服务。
• [ ] 没有挂载 ~/.ssh、云凭据和钥匙串导出物。
• [ ] 容器退出后，container ls 不再显示该一次性实例。
• [ ] git diff 只出现预期改动。
• [ ] 失败命令能够返回非零状态，而不是静默通过。
• [ ] 缓存和中间产物没有回写宿主机其他目录。

如果原始仓库发生变化，立即停止自动执行，删除工作副本并从干净提交重新创建。不要试图通过追加更多黑名单来“修补”已经错误的挂载设计。

个人方案与团队方案：什么时候应该换成独立 Mac 环境

本地 Apple Container 适合个人开发者和小型团队的短任务。它启动快、脚本容易版本化，适合依赖安装、测试、编译和一次性代码实验。

但以下情况不适合继续把所有风险压在本机：

• 多人并发运行 Agent，权限策略需要统一下发；
• 任务必须访问完整 macOS、Xcode、模拟器或原生签名链；
• 需要远程访问、审计日志和一键重置；
• 不能把个人电脑上的文件、密钥和开发环境暴露给自动化任务；
• 需要长期稳定运行，而不是每次任务后销毁。

当前本机方案的真实缺点通常有三个：你仍要维护脚本和镜像；一旦错误地挂载目录，宿主机数据仍可能被删除；多人协作时，审批、凭据和版本无法天然统一。相比之下，MacHTML 提供的临时 Mac 体验更适合把高风险 Agent 任务放到可重置、可单独交付的环境中，尤其是测试陌生代码、验证自动化流程或临时复现问题时。

如果你只需要短期算力、一次性测试环境或隔离的 Cursor Agent 工作区，可以先参考 MacHTML 帮助中心 了解交付方式，再根据是否需要完整 macOS 图形流程，对照 MacHTML 的 Mac 方案 做本地容器与独立环境的取舍。长期稳定重负载、必须连接本地物理设备，或需要持续保留完整开发状态时，自购 Mac 可能更合适；但对临时、高风险、需要快速回滚的 Agent 任务，独立可重置环境通常更容易验收。