打開 Claude Desktop，切到 Cowork 分頁，丟一句「幫我把這個資料夾裡的 CSV 全部分析整理一遍、輸出統計報表」。接下來會發生什麼事？
AI 開始在你的硬碟上動手——讀檔案、跑 Python 腳本、安裝套件、寫新檔案。對話視窗關掉之後，排程任務還會繼續在背景跑。
這跟一般的聊天差很多。一般的聊天最多就是給你一段程式碼，跑不跑由你決定。Cowork 把「執行」這一步直接接管了。
問題是：你怎麼確定它不會把家目錄亂寫一通？
Anthropic 的答案是把整個執行環境關進一台 VM——不是 chroot、不是命名空間、不是 process-level 沙箱，而是貨真價實的虛擬機器，跑在你自己的電腦上。
這篇拆解這套設計，並對比 macOS 與 Windows 兩個平台的實作差異。
為什麼 Cowork 走 VM 隔離，不走 process sandbox？
如果你看過 Claude Code 的沙箱設計，會發現它走的是「process-level 沙箱」路線：macOS 用 Seatbelt（sandbox-exec），Linux 用 Bubblewrap。沙箱是直接套在執行中的程序上，不另外開 VM。
Cowork 不走這條路。官方文件寫得很直白：
Shell commands and code Claude writes run inside an isolated virtual machine (VM), separate from your main operating system.
兩種設計的差異，其實是在回答同一個問題：AI 自主執行的範圍有多廣，需要多硬的邊界？
| 設計取向 | Claude Code | Claude Cowork |
|---|---|---|
| 隔離層級 | Process（Seatbelt / Bubblewrap） | 整台 VM |
| 啟動成本 | 幾乎 0 | 要先把 VM 跑起來 |
| 範圍 | 終端工作流，由你緊盯 | 長時間任務，可能在你不在時跑 |
| 越界後果 | 受限的系統呼叫被攔截 | 越界根本碰不到主機核心 |
Claude Code 假設你會盯著螢幕。Cowork 不能這樣假設——它的賣點之一就是排程任務、長時間自主執行。沒人盯著的時候，邊界就得更厚。
VM 的代價是啟動成本和效能開銷。Cowork 用「啟動慢、執行重」換來「越界根本碰不到主機」這個保證。
隔離模型：在你的電腦裡開一台 VM
Cowork 的執行流程大致是這樣：
- 你下達任務，Claude 在主程式（Claude Desktop）裡規劃步驟
- 需要跑 shell 或程式碼時，把工作交給本機的 VM
- VM 透過受控通道存取你授權的檔案夾
- 結果送回主程式，整理輸出
關鍵在「受控通道」這一段。AI 看到的不是你的整顆硬碟，是一份你明確授權過的清單。
檔案存取
Claude can only read and write files in folders you’ve connected.
這跟 Claude Code 的「預設整顆電腦都能讀、寫入只限工作目錄」相反——Cowork 的預設是什麼都看不到，你勾哪個資料夾它才看得到哪個。
實作上推測是把授權路徑掛載進 VM。這也是後面 Windows 上會出現「跨磁碟掛載失敗」問題的伏筆。
網路存取
走 egress 設定（Settings > Capabilities）。團隊版／企業版的管理員可以從 organization settings 全域關掉某些能力（例如 web search）。
VM 預設沒有「無條件對外連線」這回事，需要顯式打開。
兩種權限模式
| 模式 | 行為 |
|---|---|
| Ask before acting | 每個動作都先暫停詢問 |
| Act without asking | 不打斷，自己一路做完 |
不過有一條鐵則：刪除操作不管在哪個模式下都要你親自批准。這是個合理的硬性保護——「自主執行」可以很激進，但毀掉檔案這件事必須留給人類拍板。
macOS 上的實作
macOS 這邊單純很多。
- 從
claude.com/download抓 Universal DMG，Intel 與 Apple Silicon 都吃 - 安裝完打開 Cowork 分頁就能用
- 沒有額外服務要啟動，也沒有要選擇「兩種安裝器」的問題
官方沒明說底層用什麼虛擬化框架。但從「Universal binary 一份打天下」「不需要管理服務」「Apple Silicon 上原生跑得起來」這幾點推測，很可能是直接用 Apple 內建的 Virtualization.framework。這是 macOS 11 之後 Apple 官方推的輕量級虛擬化 API，Docker Desktop、UTM、OrbStack 都在用。
如果這個推測沒錯，Cowork 在 macOS 上「安裝簡單」就有了解釋：虛擬化能力是 OS 內建，App 直接呼叫就行，不需要安裝額外的 hypervisor 或服務。
Windows 上的實作
Windows 這邊複雜得多，因為 Anthropic 在 Windows 上面對一個歷史包袱：用哪種安裝器。
MSIX 還是 Squirrel？
Claude Desktop 的 Windows 版本 過去用的是 Squirrel（.exe 自動更新框架，Slack、Discord、VS Code 早期都用過）。後來改用 MSIX，這是 Windows 10 之後微軟力推的容器化打包格式。
兩者的差別不只是「換個安裝器」。MSIX 允許 App 註冊 Windows 服務、用容器化的方式存取系統資源、支援 Microsoft Store 配發。Cowork 的 VM 啟動需要一個常駐的 Windows 服務來接管——這在 MSIX 包裡是 first-class 設計，Squirrel 包裡是事後黏上去的。
實際結果是：
This can happen if you installed Cowork via the older .exe/Squirrel installer instead of MSIX.
如果你還在用舊安裝器，VM 服務可能根本沒被註冊，Cowork 就不能用。處理方法是解除安裝後從 claude.com/download 重抓 MSIX 版。
Claude VM Service
Cowork 在 Windows 上依賴一個常駐服務：
| 服務名稱 | 適用情境 |
|---|---|
CoworkVMService | 從 claude.com/download 安裝的 MSIX |
CoworkVMServiceStore | 從 Microsoft Store 安裝的版本 |
服務沒跑，VM 就起不來。錯誤訊息會是 VM service not running。
可以從「服務」應用程式（services.msc）裡確認狀態，或是用 PowerShell：
# 確認服務存在且狀態為 Running
Get-Service CoworkVMService
# 手動啟動
Start-Service CoworkVMService如果服務不存在，那就是安裝器或 MSIX 包出問題了，重灌是最快的修法。
「EXDEV: cross-device link not permitted」
這個錯誤很常見，背後的原因會讓你對前面講的「掛載授權資料夾進 VM」有更具體的體會。
EXDEV 是 POSIX 錯誤碼，意思是「跨磁碟裝置的硬連結不允許」。在 Cowork 的情境裡，它通常代表：Cowork 預設把工作儲存路徑放在 C:\，但你的某個授權資料夾在 D:\，VM 嘗試在這兩條掛載之間做檔案操作時就會炸。
幾個常見觸發情境：
- Cowork 的 storage path 被改到非 C:\ 的磁碟
- 公司透過 roaming profile 把 AppData 重導到網路位置
- 同一個任務裡跨磁碟搬移檔案
修法：
- 把 storage path 重設回 C:\（Cowork 設定裡）
- 解除安裝，重新從 MSIX 安裝
- 如果是 roaming profile 問題，要找 IT 把 AppData 留在本機
這不是 bug，是 VM 隔離設計的副作用。VM 內部看到的檔案系統是它自己的，主機掛進來的每個資料夾各自是獨立的「裝置」，跨裝置的某些檔案系統操作（如 hard link、rename）本來就不被允許。
兩個平台的對比
把兩邊放在一起看，差異就很清楚：
| 項目 | macOS | Windows |
|---|---|---|
| 安裝器 | Universal DMG | MSIX（舊版 Squirrel 不支援） |
| 架構 | Intel + Apple Silicon 通吃 | x64 + arm64，各自一份 |
| 常駐服務 | 不需要 | CoworkVMService 必須跑 |
| 虛擬化基礎 | 推測為 Virtualization.framework（OS 內建） | 推測走 Hyper-V 或 WSL2 stack |
| 常見故障 | 幾乎沒有文件化 | 服務沒起 / 跨磁碟掛載 |
| 安裝後排錯成本 | 低 | 中——可能要手動處理服務或路徑 |
macOS 上 Anthropic 可以靠 Apple 一家供應的虛擬化 API 一以貫之。Windows 上要同時面對 MSIX vs .exe、企業 IT 環境的 roaming profile、多顆硬碟的使用習慣——這些都不是 Cowork 自己的問題，是 Windows 生態的歷史變數。
開發者實務上要知道的限制
VM 隔離不是免費午餐。實際用起來有幾個限制要先了解：
- App 必須開著，機器不能睡眠 排程任務聽起來很美好，但前提是 Claude Desktop 開著、電腦醒著。關掉 App 或進入睡眠，正在跑的工作就斷了。這不是「雲端代理」，是「本機代理」。
- Token 消耗顯著高於一般對話 Cowork 為了規劃、執行、檢視結果，會大量使用 token。把它當成 chat 用會很快燒掉額度。
- Memory 只在 project 內持久 單次對話的脈絡不會自動繼承到下一次。如果要跨 session 記住事情，得開 project 來放。
- 沒有 session 匯出或分享 跑出來的結果留在你的檔案系統，但整個對話流程連同 AI 的決策過程沒辦法直接匯出給同事看。要分享得自己截圖或手動整理。
- 沙箱不擋你自己授權的範圍 你勾了某個資料夾，AI 就能在裡面為所欲為（除了刪除）。沙箱保護的是「你沒授權的部分」，不是「你授權範圍內的失誤」。授權給家目錄等於沒授權。
結語
Cowork 跟 Claude Code 是 Anthropic 在「AI 自主執行」這條路上的兩種押注。Code 押的是「process 沙箱夠輕、迭代夠快」，Cowork 押的是「VM 隔離夠厚，可以放手讓它跑」。
這兩種設計沒有誰對誰錯，只有適不適合場景的問題。要 AI 在你眼前一邊改 code 一邊跑測試，Process 沙箱的低延遲贏；要 AI 在你睡覺時排程跑半小時的資料清洗，VM 隔離的安全邊界贏。
實際用 Cowork 的時候，把它想像成「一台寄宿在你電腦裡、跟你共用部分檔案夾的小機器」。授權什麼進去、放它跑多久、出問題時去哪查服務，這個畫面想清楚了，Windows 上那些奇怪的服務名稱和跨磁碟錯誤訊息，就會從「莫名其妙的 bug」變成「合理的副作用」。