2026 Cursor Agent 怕誤刪檔案？用 Apple Container 搭隔離沙箱

症狀： Cursor Agent 能直接改檔、裝套件、跑終端機指令，誤刪或讀取宿主機資料的風險不容易靠人工盯住。
最快解法： 使用「可丟棄程式碼副本 + Apple Container 受限執行」的雙層方案，不要把唯一原始專案、家目錄或個人金鑰掛進容器。

這篇適合經常讓 Cursor Agent 自動安裝依賴、執行測試或修改多檔案專案的個人開發者。
如果你要替團隊統一 AI Agent 的執行邊界，或正在比較本機沙箱與可重設的隔離 Mac 環境，也可以直接從下方的驗收流程開始。

最後更新於 2026 年 8 月 29 日；Apple Container 版本、系統需求與指令參數核對自官方儲存庫、版本頁面與命令參考。

先分清楚：Cursor Agent 沙箱保護的是哪一層

Apple Container 在 Apple Silicon Mac 上執行 Linux 容器。它採用輕量虛擬機承載 Linux 工作負載，並不是在容器內啟動完整 macOS。官方目前以 macOS 26 為主要支援版本，且要求 Apple silicon Mac；截至本文更新日，版本頁面顯示最新穩定版本為 1.3.0。相關條件可參考官方需求與安裝說明。(github.com)

這個邊界會直接影響你的選擇：

• 適合放進容器： Linux 依賴安裝、程式碼產生、編譯、單元測試、靜態檢查、腳本執行。
• 不適合直接搬進容器： Xcode GUI、原生 macOS 簽章、需要 Keychain 的流程、完整 iOS 建置鏈，以及依賴實體 USB 或模擬器的工作。
• 不能誤解的地方： Apple Container 可以限制容器內的檔案系統與網路，但只要你把宿主機目錄以可寫方式掛載進去，容器內的程式仍可能刪除該目錄裡的資料。

Cursor 的終端機核准、Run Mode、規則與 .cursorignore 是應用層護欄，不是完整的檔案系統安全邊界。官方明確指出 Run Mode 屬於盡力而為的防護；.cursorignore 也不能阻止終端機或 MCP 工具存取被忽略的檔案。(prod.cursor.com)

Apple Container 能否完全取代其他容器工具來隔離 AI 編程助手？
不能用「完全取代」來理解。它在 Apple Silicon 與 macOS 26 上能提供原生整合的 Linux 容器執行方式，但生態成熟度、團隊標準化、跨平台相容性與 macOS GUI 工作流程仍需另行評估。本文的方案是縮小 Cursor Agent 的執行面，不是宣稱所有開發工作都應搬進 Linux 容器。

準備階段：先複製專案，再讓 Agent 動手

最常見的錯誤不是容器指令寫錯，而是把唯一工作副本直接交給 Agent。你應先建立一個能刪、能重建、能丟棄的工作區。

可以選以下其中一種：

1. 由 Git 重新複製一份臨時工作區。
2. 使用 git worktree 建立獨立分支目錄。
3. 將目前專案同步到專用暫存目錄，再讓 Cursor 開啟該目錄。
4. 對尚未提交的變更先產生 patch 或壓縮備份。

同時放入一個誘餌檔案，例如：

mkdir -p "$HOME/agent-sandbox-check"
printf 'do-not-delete-host-check\n' > "$HOME/agent-sandbox-check/host-canary.txt"

這個檔案不應掛載到容器。驗收時，你會故意要求 Agent 執行刪除測試，確認它只能影響容器中的工作副本。

先檢查基本條件：

uname -m
sw_vers
container --version
container system version
container system start

你要看到的是 Apple Silicon 架構、macOS 26，以及可正常回應的 Apple Container 服務。container system start 是官方教學要求的初始服務啟動方式；不要自行猜測不存在的 YAML 設定格式。Apple Container 的一般執行參數由 container run、--mount、--read-only、--tmpfs、--network 等 CLI 選項提供。(github.com)

哪些 Mac 和 macOS 版本可以執行 Apple Container？
目前應以 Apple silicon Mac 與 macOS 26 作為正式部署基準。官方原始碼建置文件仍提到 macOS 15 的最低建置條件，但也列出 macOS 15 在網路建立、網路命令與多網路管理方面的限制；如果你要依本文做網路隔離驗收，優先使用 macOS 26。(github.com)

建置階段：用非 root 映像檔包住常用工具

建立資料夾：

mkdir -p ~/cursor-agent-sandbox
cd ~/cursor-agent-sandbox

新增 Dockerfile：

FROM alpine:3.22

RUN apk add --no-cache \
    bash \
    ca-certificates \
    git \
    make \
    g++ \
    python3 \
    nodejs \
    npm \
    openssh-client \
  && addgroup -g 1000 agent \
  && adduser -D -u 1000 -G agent agent

USER agent
WORKDIR /workspace

ENTRYPOINT ["/bin/sh", "-lc"]

這個映像檔只放入常用 Linux 工具鏈。真正的專案依賴，例如 JavaScript 套件或 Python 套件，建議在「有明確需要時」執行一次依賴準備，再把一般測試改成離線執行。否則每次讓 Agent 執行安裝命令，都可能把不受控的外部內容引入工作區。

建置映像檔：

container build --tag cursor-agent-sandbox:local --file Dockerfile .

官方命令參考目前支援從 Dockerfile 或 Containerfile 建置 OCI 映像，也支援 --tag、--file 與建置資源參數。本文不使用未經官方文件確認的專用 YAML。(github.com)

接著新增 sandbox-run.sh：

#!/usr/bin/env bash
set -euo pipefail

IMAGE="cursor-agent-sandbox:local"
WORKSPACE="${1:-}"
ALLOW_NETWORK=0

if [[ "${WORKSPACE}" == "--allow-network" ]]; then
  ALLOW_NETWORK=1
  WORKSPACE="${2:-}"
  shift 2
else
  shift || true
fi

if [[ -z "${WORKSPACE}" || ! -d "${WORKSPACE}" ]]; then
  echo "用法：$0 [--allow-network] /path/to/disposable-workspace command..."
  exit 2
fi

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

NETWORK_ARGS=(--network none)
if [[ "${ALLOW_NETWORK}" == "1" ]]; then
  NETWORK_ARGS=(--network default)
fi

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

加上執行權限：

chmod +x sandbox-run.sh

這支腳本有五個安全作用：

• --rm：容器停止後自動移除執行個體。
• --read-only：把容器根檔案系統設為唯讀。
• --mount：只把你指定的可丟棄工作區掛到 /workspace。
• --tmpfs：把暫存檔與快取放到容器記憶體中的臨時檔案系統。
• --user 1000:1000：避免一般任務以 root 身分執行。

Apple Container 官方文件說明，唯讀掛載與 tmpfs 都是 container run 的正式選項；tmpfs 在容器停止後會消失。(github.com)

方案對比：本機雙層隔離與直接開放工作區

如果任務只需要 npm test、python -m pytest、make test 或靜態檢查，第二種通常是成本與隔離程度較平衡的選擇。若任務必須操作 Keychain、登入 GUI 工具或使用 USB，則不要硬塞進 Apple Container。

接入階段：讓 Cursor 只呼叫包裝腳本

把 Cursor 開啟的工作區指向臨時副本，而不是原始倉庫。你可以在專案規則中寫清楚：

所有建置、測試、依賴檢查與可執行腳本，必須透過 ./sandbox-run.sh 執行。
禁止直接使用宿主機的家目錄、SSH 設定、雲端憑據、Keychain 匯出檔或生產環境變數。
任何刪除檔案、發布、修改宿主機設定或注入憑據的操作，必須先停下來請求人工確認。

這些規則能改善 Agent 的操作路徑，但不能把它們當成硬性隔離。Cursor 官方文件指出，Agent 可以直接修改工作區檔案，終端機執行則受 Run Mode 與核准設定影響；非互動模式還可能給予 Agent 完整寫入權限。(prod.cursor.com)

允許自動執行的範圍，建議限於：

• 讀取版本控制狀態。
• 執行單元測試與靜態檢查。
• 在容器內執行建置命令。
• 讀取編譯輸出與測試報告。
• 清理容器內的暫存檔。

必須人工確認的範圍：

• rm、大量移動或覆寫檔案。
• 讀取或注入 SSH、雲端、套件註冊表與生產憑據。
• git push、發佈、部署與修改 CI 設定。
• 修改宿主機設定、安裝系統元件或操作其他專案目錄。
• 把新的宿主機路徑加入可寫掛載。

如何限制 Cursor Agent 只能修改指定專案目錄？
靠 .cursorignore 不夠。實際限制應由「Cursor 開啟可丟棄副本」加上「容器只掛載該副本」完成。掛載時不要使用 $HOME、整個專案父目錄或任何含有其他倉庫的上層路徑。因為可寫掛載本身就代表容器內程式可以修改宿主機對應目錄。

網路與金鑰：預設拒絕，必要時短暫放行

一般測試使用：

./sandbox-run.sh ~/cursor-agent-workspace npm test

腳本會套用 --network none。這表示測試流程無法連線外部網路，適合已完成依賴安裝、只需要重現建置或驗證行為的任務。

若確實需要下載依賴，使用明確的放行模式：

./sandbox-run.sh --allow-network ~/cursor-agent-workspace npm ci

下載完成後，回到無網路模式執行測試：

./sandbox-run.sh ~/cursor-agent-workspace npm test

Apple Container 的官方命令參考支援 --network，而 macOS 26 也支援建立隔離網路；官方 how-to 文件另外說明，--network none 可讓容器不掛接網路。(github.com)

Apple Container 怎樣關閉外部網路並隱藏本機金鑰？
關閉網路要在執行命令層使用 --network none，隱藏金鑰則要從掛載與環境變數兩端處理。不要掛載 ~/.ssh、雲端 CLI 設定、憑據檔、Keychain 匯出物，也不要使用會自動繼承宿主機環境變數的寫法。若某個任務必須登入，使用短期、最小權限憑據，任務完成後立即撤銷。

命令黑名單不能取代這些邊界。即使你封鎖了某個 rm 形式，Agent 仍可能透過 Python、Node.js、Shell 重新實現相同的檔案操作；真正重要的是它看得到哪些路徑，以及能否連到外部服務。

驗收階段：先做破壞性測試，再交給日常任務

首次接入不要直接跑正式專案。先建立最小驗收副本：

git clone /path/to/original-repository ~/cursor-agent-workspace
printf 'container-canary\n' > ~/cursor-agent-workspace/CANARY.txt

在容器內執行：

./sandbox-run.sh ~/cursor-agent-workspace \
  sh -c 'printf "changed\n" > CANARY.txt && rm -f CANARY.txt && pwd && id'

接著檢查：

test -f /path/to/original-repository/CANARY.txt
test -f "$HOME/agent-sandbox-check/host-canary.txt"
container list --all
git -C /path/to/original-repository status --short

你要得到以下結果：

• 原始倉庫的誘餌檔案仍然存在。
• 主目錄中的宿主機誘餌檔案仍然存在。
• 容器內的 CANARY.txt 可以被刪除。
• 容器停止後，container list --all 不應留下這次執行的容器。
• 沒有 SSH、雲端憑據或生產環境變數被放入工作區。
• 專案差異只出現在可丟棄副本，且能透過 Git 還原。

你可以把以下清單交給團隊作為每次變更前的門檻：

• [ ] 確認 Mac 使用 Apple silicon。
• [ ] 確認系統為 macOS 26，且 container system start 成功。
• [ ] 確認使用 Apple Container 的穩定版本，而非未核實的開發分支。
• [ ] 建立 Git clone、worktree 或同步副本。
• [ ] 確認 Cursor 開啟的是可丟棄工作區。
• [ ] 確認容器只掛載 /workspace 對應的副本目錄。
• [ ] 確認根檔案系統使用 --read-only。
• [ ] 確認快取與暫存資料使用 tmpfs 或其他可丟棄位置。
• [ ] 確認沒有掛載家目錄、SSH、Keychain 或雲端憑據。
• [ ] 無需下載依賴時使用 --network none。
• [ ] 驗證容器內可刪除副本檔案，但不能刪除原始倉庫。
• [ ] 驗證退出後容器、日誌與臨時憑據都已清理。

若其中一項失敗，先停止讓 Agent 自動執行。回到「重新複製副本、縮小掛載、移除憑據、關閉網路」的順序，不要用更多規則掩蓋邊界錯誤。

維護選擇：個人本機與團隊隔離環境

個人開發者可以把映像檔與 sandbox-run.sh 一起提交到專案內，但不要把任何秘密值寫進 Dockerfile、規則檔或腳本。每次更新工具鏈時重新建置映像，並在乾淨副本上重跑誘餌檔案驗收。

小型團隊則要額外處理三個問題：

• 多人是否使用同一套映像檔與版本。
• 任務失敗後能否一鍵丟棄並重建。
• 每位成員是否都遵守相同的網路與憑據注入規則。

如果你需要多人並發、統一映像、遠端存取、快速重設，或必須讓高風險 Agent 任務與個人工作站完全分離，本機容器就未必是長期終點。此時應評估獨立或雲端隔離 Mac，而不是持續增加宿主機掛載權限。你也可以先閱讀 MacHTML 的隔離開發環境使用說明，再依工作流程比較不同 Mac 使用方案。

最後，若你目前的方案是直接在宿主機執行 Agent，常見缺點是：原始倉庫與測試副本容易混在一起、個人金鑰可能被終端機流程讀到、失敗後很難還原乾淨狀態；若是多人共用同一台 Mac，權限與清理責任也更難追蹤。把高風險任務交給 MacHTML 的可重設 Mac 環境，會比持續擴大本機掛載範圍更容易建立明確邊界。若你只需要短期測試環境、臨時算力或一次性的 Agent 工作區，這種方式尤其值得納入比較；但長期固定重負載、需要實體介面或必須直接操作本機 Keychain 的流程，仍應保留實體 Mac 或專用開發環境。