2026 Cursor Agent 團隊沙箱怎麼配？Apple Container 分角色方案

macOS 26 與 Apple Silicon 已被 Apple Container 官方定位為執行 Linux 容器的系統條件，而不是把 macOS 應用程式直接裝進容器；詳見 Apple WWDC25 Containerization 介紹。因此，本週不要把一份寬鬆沙箱設定複製給全員：普通開發先使用 Cursor 原生沙箱，依賴安裝與高風險倉庫腳本再套 Apple Container，簽名、發布憑證和生產操作則保留人工審批，必要時移到獨立 Mac 環境。

本週建議時間表

• 第 1 天：盤點每個角色會讀取、寫入、連線和執行的資源。
• 第 2 天：先發布個人開發與功能開發的最低權限設定。
• 第 3 天：把維護腳本和第三方建置工具移到臨時倉庫副本。
• 第 4 天：為建置快取、套件來源和測試服務建立有期限的例外。
• 第 5 天：由平台或安全負責人演練回滾，確認簽名及發布權限沒有落入普通會話。

這篇適合研發負責人制定 Cursor Agent 統一基線，也適合倉庫維護者、建置工程師及發布安全負責人檢查自己的升級路徑。若團隊只需要偶爾測試小型專案，未必需要額外的雲端環境；若同時存在敏感倉庫、多人並行和發布流程，則應把高風險執行面獨立出去。

先分清楚「可寫」與「可恢復」

一份曾被團隊廣泛複製的寬鬆設定，可能讓普通開發者同時取得建置目錄、共享憑證、發布腳本和全部網路權限。問題不在於某個 Agent 是否足夠聰明，而在於同一個會話一旦獲得過寬的檔案和命令權限，錯誤操作的影響範圍會跟著擴大。

至少有四項隱性成本需要先處理：

1. 工作區寫入不代表資料安全：Agent 可以只被允許寫入目前倉庫，但仍可能覆蓋未提交的工作、修改 Git hooks，或讀取倉庫內不應進入模型上下文的設定檔。
2. 主目錄掛載會放大洩漏面：SSH 設定、雲端認證、套件管理器憑證和其他專案資料通常散落在主目錄；把整個主目錄交給工具，等於把隔離邊界改成「整台電腦」。
3. 全開網路很難追責：依賴下載、遠端測試和映像檔拉取有正當用途，但任意外連也可能把環境資訊或原始碼送到未核准服務。
4. 角色混用會造成權限累積：建置工程師需要快取和測試服務，不代表他需要簽名憑證；倉庫維護者需要遷移腳本，也不代表他可以碰生產令牌。

Cursor 的 Run Modes 官方文件 和 Terminal 保護機制說明 應作為最低基線。無論使用哪種模式，程式碼都應先進入可恢復的 Git 分支或副本，再讓 Agent 執行可能大量改寫的工作。

個人開發者的最低權限基線

個人開發者的日常任務通常是產生程式碼、執行靜態檢查和單元測試，這些工作不需要讀取主目錄，也不需要存取生產環境。Cursor Agent 團隊沙箱配置的第一層，應是「目前工作區可寫、其他資料唯讀或不可見、危險命令需要確認」。

建議允許：

• 目前專案的原始碼、測試資料和本地建置輸出；
• 讀取版本控制狀態，建立分支、提交或產生差異檔；
• 存取已列出的套件下載來源；
• 執行靜態分析、單元測試和不涉及真實服務的本地測試。

建議禁止：

• 整個主目錄、整個使用者憑證目錄和其他專案根目錄；
• 修改 Git 全域設定、Shell 啟動檔和系統設定；
• 未經確認的破壞性檔案操作、資料庫清空和生產連線；
• 將私人金鑰、長期令牌或鑰匙串內容加入會話可見範圍。

這一層先不處理 Apple Container 安裝。原因很實際：若每個普通編輯、測試工作都跳到容器，團隊會為了方便而把掛載和網路例外逐步放寬，最後反而失去可審查性。平台可先參考我們的 Mac 開發環境服務入口，把本機權限盤點完成後再決定是否需要獨立執行環境。

功能開發成員的倉庫邊界

功能開發成員的目標不是「完全不能執行命令」，而是只能操作目前倉庫及該任務必要的外部資源。使用者層設定適合放個人最低權限，專案層 sandbox.json 則負責團隊共同規則；字段名稱、允許與拒絕的合併方式，應逐項對照 Cursor sandbox.json 字段文件，不要根據其他工具的格式自行猜測。

長尾問題的答案也因此很明確：Cursor Agent 團隊成員不應使用完全相同的 sandbox.json。團隊可以共用基線，但專案策略應限制倉庫範圍，角色例外則另外登記。若使用者層允許某項資源、專案層拒絕該資源，實際結果必須以 Cursor 官方文件描述的策略優先關係為準，並在升級版本後重新驗證。

倉庫維護者的雙層隔離

資料庫遷移、批量改寫、程式碼生成和第三方安裝腳本，往往會建立檔案、修改依賴或執行專案以外的工具。即使 Cursor 原生沙箱限制在工作區，腳本仍可能利用現有工具鏈接觸更多資源，因此這類任務不應直接在主要工作副本中執行。

Apple Container 適合在這裡提供第二層隔離，但它執行的是 Linux 工作負載。Apple 官方的 Containerization 架構說明 和 Apple Container 官方說明 可用來核對架構、系統條件和版本狀態。

倉庫維護者可按以下方式落地：

1. 建立臨時 Git worktree 或獨立副本，先記錄來源提交。
2. 只複製任務需要的輸入檔，不掛入主目錄、SSH 目錄或通用認證目錄。
3. 在 Apple Container 內執行遷移、生成或第三方腳本，輸出寫到指定結果目錄。
4. 先檢查差異檔、產生檔和依賴變更，再合併回正式分支。
5. 任務結束後刪除容器與臨時副本，保留日誌、提交雜湊和審批記錄。
6. 若工作需要 Xcode、模擬器、原生 macOS Framework 或鑰匙串，停止容器方案，改由受控 Mac 流程處理。

提醒：Apple Container 不是 macOS 應用程式容器。它能隔離 Linux 工作負載，不代表 Xcode 建置、iOS 模擬器、macOS 原生簽名和鑰匙串操作都能在其中直接完成。

建置測試工程師的受控例外

建置角色比一般開發者需要更多權限，但「建置成功」不是把所有網路和宿主路徑打開的理由。Apple Container 的 掛載與卷文件 以及 網路配置文件 應作為核對依據，尤其要確認唯讀掛載、可寫快取與網路設定在團隊採用的穩定版本中如何表現。

建置例外至少要有四個狀態：申請、核准、到期和撤銷。若離線、套件鏡像不可用或快取失效，降級路徑應是「在隔離環境重新下載並失敗即停」，而不是臨時改成全網路、全主目錄模式。本文不宣稱容器一定帶來性能收益；任何資源消耗或速度結論，都應以官方資料或本站針對指定配置的實測為準。

角色 FAQ：把例外留在正確的人手上

團隊基線與個人例外

團隊策略可以規定所有會話不得讀取通用憑證、所有破壞性命令必須確認，以及所有高風險腳本使用臨時副本；個人設定只能收緊範圍，不能自行把生產權限加回來。這種分層可避免同事複製舊檔案後，無意中繼承建置或發布能力。

Apple Container 的使用門檻

若任務只涉及目前倉庫內的編輯、檢查和單元測試，Cursor 原生沙箱通常較容易維護。若任務包含來源不明腳本、批量改寫、遷移或需要試驗性依賴，才進入 Apple Container；若需要 macOS 原生工具鏈，則應改走受控 Mac，而不是強行改造 Linux 容器。

快取與依賴的最小開放

快取應該是專用、可寫、可清理的目錄；依賴來源則以網域或端點列舉。建置工程師不需要看到其他專案的快取，也不應因為下載失敗而取得主目錄權限。例外若沒有到期日，就不是例外，而是永久權限。

簽名和發布的人工閘門

程式碼準備和建置驗證可以由 Agent 協助，但簽名、發布和生產變更應分成獨立步驟。憑證不放入通用容器，發布令牌不放入普通會話；受控 Mac 上的人工確認、短時效授權和審計記錄，才是發布邊界。

發布與簽名的獨立執行面

發布人員需要的不是更寬鬆的 Cursor 設定，而是更清晰的流程拆分：

Linux 容器不能直接替代依賴 macOS 原生簽名工具、鑰匙串、Xcode 或模擬器的階段。即使團隊使用短時效令牌，也不能把令牌掛入所有人的工作區；應由發布流程在最後一步注入，完成後立即撤銷或失效。

平台安全負責人的決策分支

平台負責人可用以下條件列表取代「所有人一套設定」：

• 若任務只有編輯、靜態檢查和單元測試，選 Cursor 原生沙箱；若需要主目錄、通用憑證或生產端點，回退到人工處理。
• 若任務會執行第三方腳本、遷移、批量生成或大規模改寫，選 Apple Container 加臨時倉庫副本；若依賴 macOS 原生工具鏈，回退到受控 Mac。
• 若建置需要外部依賴或快取，只增加列明的網域、唯讀路徑和專用可寫快取；若無法列舉來源，回退到隔離的臨時環境，不開放全部網路。
• 若任務涉及簽名、鑰匙串、發布令牌或生產操作，選獨立受控 Mac 和人工確認；普通 Cursor Agent 會話及通用容器都不得取得這些資料。
• 若多人同時操作敏感倉庫，或例外無法在期限內撤銷，評估獨立雲端 Mac；若團隊需要比較自購、雲端和租賃的總成本，可先查看 JexMac 方案與計費頁面，再按實際交付條件核算。

最後形成一份版本化矩陣，至少記錄角色、允許資源、禁止資源、例外期限、審批人、破壞性測試方式和回滾責任人。每次 Cursor 調整 Run Modes 或 sandbox.json 結構、Apple Container 發布新穩定版本，或 macOS 大版本改變兼容邊界，都要重新核對官方文件，而不是沿用舊設定。

從本機沙箱轉向獨立 Mac 的成本判斷

本機 Cursor 沙箱的優點是啟動快、日常編輯成本低；Apple Container 適合隔離 Linux 腳本和臨時倉庫副本，但需要管理掛載、網路和工具鏈邊界。兩者都不適合直接承擔需要原生簽名、鑰匙串或生產發布的完整流程。

若團隊目前的方案是「每位員工自行維護一份寬鬆設定」，真實缺點通常包括：權限難以集中撤銷、敏感資料容易跟著主目錄被掛入、多人並行時缺乏一致審計，而且發布操作會與日常開發混在同一台 Mac 上。這時，把高風險任務遷移到獨立的 Mac 環境，往往比繼續堆疊本機例外更容易驗收；JexMac 的 Mac 環境交付入口 可作為下一步評估起點。

在採取任何方案前，先填好本文的角色權限矩陣：能留在本機的任務留在本機，需要 Linux 隔離的任務進 Apple Container，涉及簽名發布或多人敏感操作的任務則另行安排受控 Mac。這樣租賃 Mac 的價值不在於替每個人增加一台設備，而在於把最難回收、最難審計的執行權限，從日常 Cursor Agent 會話中正式拆開。

常見問題