hero

如果你讓 Claude Code 寫了一個 rm -rf ~/ 的指令，而你真的執行了——那不是 Claude Code 的錯，是你讓它碰了不該碰的東西。clawk 做的事情非常簡單，但幾乎沒有人在做：給 coding agent 一台它自己的 Linux VM，你的主機它碰不到。這個工具才 v0.2.0、stars 還沒破三百，但它的設計哲學值得認真討論——因為它解決的不是技術問題，是「大家懶得做」的問題。

原文摘要

Clawk 是一個開源 Go 工具（目前 v0.2.0，278 stars，Apache 2.0），由 Salim Alami 開發，目標非常聚焦：為 AI coding agent（Claude Code、Codex、OpenCode 等）提供一次性的 Linux VM，讓 agent 在自己的機器上工作，而不是你的。支援 macOS（Apple silicon）和 Linux（firecracker，實驗性）。

一句話講完這個工具：cd 進你的 repo，輸入 clawk，agent 就在一個隔離的 VM 中工作——你的檔案、keychain、整個主機都碰不到。Agent 得到自己的機器，不是你的。

作者解釋了為什麼選擇 VM 而非更輕量的 sandbox。第一，獨立 kernel——guest 跑自己的 Linux kernel，host 檔案系統從未被掛載進 VM。第二，標準 Linux 環境——標準 kernel、標準 userland、/dev/kvm，工具行為與文件一致，不存在「這個 sandbox 不支援那個 syscall」的問題。第三，guest 內有 root——agent 可以安裝系統套件、編輯 /etc、載入 kernel 模組、綁定 privileged port，這些在 container sandbox 裡需要特殊配置或根本做不到。第四，一次性生命週期——搞爛了就 clawk destroy && clawk，回到原點，repo 和對話記錄完好無損。第五，更強的隔離——隔離依賴的是 hypervisor 邊界，不是 process-sandbox 政策的正確性。隔離不是 prompt 裡的一條規則（agent 可以用話術繞過），而是一台獨立的機器。

作者用三個 shell 範例展示隔離效果。從 sandbox 內執行 curl https://tracker.evil.example——不在白名單內，直接連線失敗。cat ~/.ssh/id_rsa——你的金鑰從未進入 VM，檔案不存在。但 git push 可以正常運作——因為 ssh-agent 被轉發進 VM，金鑰本身沒有進入 VM，agent 可以用但拿不到。

安裝非常直接：macOS 上 brew install clawkwork/tap/clawk。日常使用流程設計得很直覺——cd 進專案目錄，clawk 啟動 sandbox 並附加 Claude；clawk run shell 進入同一個 sandbox 的 shell；clawk run codex 切換到其他 agent；clawk down 停止 VM（repo 和 agent 狀態保留）；clawk attach 稍後回來繼續；clawk destroy 移除 VM（對話歷史保留）。還有專門為多 repo ticket 設計的模式：clawk work INFRA-123 建立一個 sandbox，每個 repo 一個 worktree，自動附加 Claude；完成後 clawk pr INFRA-123 自動 push branches 並為每個 repo 開一個 PR。

技術架構方面，虛擬化層有兩個 backend：macOS 使用 Apple Virtualization.framework，直接連結進 binary；Linux 使用 firecracker（實驗性）。完全不需要 Docker、qemu、sudo。網路模型是預設 deny-all 白名單，可透過 clawk network allow 新增允許的 hostname。ssh-agent 轉發讓金鑰不需要進入 VM。

儲存模型的設計也值得注意：從 OCI image 建構 rootfs（拉取 → flatten → ext4），之後的啟動是 copy-on-write clones，kernel direct-boot——不需要 firmware、不需要 installer，秒級啟動。閒置 VM 會釋放記憶體至約 1 GiB，30 分鐘後自動停止，支援手動 snapshot 到磁碟。

持久性規則分三個層級：你的 repo（mount worktree）在 clawk down 和 clawk destroy 後都保留；agent 狀態（對話、記憶）同樣在兩種情況下都保留；VM 磁碟（apt installs、caches、$HOME）則在 clawk down 時保留，clawk destroy 時清除。這個設計讓 VM 本身是可以隨手拋棄的，但你的程式碼和對話歷史永遠不會遺失。

安全性模型是這份 README 最值得細讀的部分——因為它誠實。clawk 保護的範圍：host 檔案系統（從未進入 VM）、host secrets 和 keychain、任意網路存取（僅白名單可連線）、persistent tampering（VM 可摧毀重建，無法永久汙染主機）。

clawk 明確列出它不保護的範圍：你掛載或允許的內容（worktrees 可寫，agent 可以 commit 壞程式碼或推送到任何 ssh-agent 可觸及的 repo）、你推送進去的 secrets（files()、shares()、轉發的 env vars、Claude token 都在 agent 的視線內）、hypervisor escapes（clawk 依賴 Virtualization.framework 或 KVM 的隔離能力，不在此之上增加防禦層）。

路線圖有三個主要方向：閒置時自動 suspend-to-disk（從手動 clawk snapshot/resume 進化）、VM 上限管理（記憶體不足時 suspend 最不活躍的 sandbox 而非拒絕新請求）、Firecracker 對等功能（Linux 上支援 live worktree propagation 和 host-file push）。

FAQ 簡短回答了關鍵問題。開銷方面：首次啟動需要一次性 rootfs 建構，之後是 copy-on-write clones 加 direct-boot，秒級啟動。Intel Mac 和 Windows 目前不支援——macOS 需要 Apple silicon（14+），Linux 仍是實驗性。不需要 Docker——輸入是 OCI images，Docker engine 完全不參與。

作者最後解釋了名字的由來：商標是爪子（claw），clawkwork 致敬《發條橘子》（A Clockwork Orange）——一台你可以上發條、放出去、隨時重置的 VM。文末附帶提醒：此專案目前 pre-1.0，變動快速，版本間可能有 breaking changes。

城武觀點

一、clawk 是對的方向——不是因為技術多創新，是因為它把正確的預設值降到了「brew install」。

VM 隔離不是新概念。bubblewrap 存在，Docker 存在，Firecracker 存在，QEMU 存在——這些東西的隔離能力在技術上完全不輸給 clawk，有幾個甚至更成熟。但問題從來不是「有沒有技術能做到」，而是「誰會在日常使用中真的跑一個 VM 來隔離 coding agent？」

答案是：很少人。設定 VM 需要理解虛擬化、網路、磁碟映射、kernel 參數——這不是一個寫 React 的前端工程師在星期二下午會想做的事。clawk 把「agent 應該有自己的機器」從進階使用者的 bash 腳本變成一個 brew install——它做的是 UX 創新，不是技術創新。

安全工具的採用率，從來不取決於它有多安全，取決於它有多容易用。clawk 做對的事是：把正確的安全預設值變成一條你懶得繞過去的指令。它不是第一個想到「agent 應該隔離」的人，但它是第一個把這句話從 Hacker News 留言區搬到 Homebrew 的人。

二、clawk 的誠實是它的優勢。

讀 clawk 的 README 最讓我意外的，不是技術架構——是它的安全性模型段落。在一個所有 coding agent 都用模糊語言描述隱私的時代——「我們重視你的安全」「你的資料受到保護」「我們採用業界最佳實踐」——clawk 的 README 直接列出三個「不保護」的清單：你掛載的內容、你推送的 secrets、hypervisor escapes。沒有模糊地帶，沒有「我們建議你」的前提，就是三行「❌」。

這種誠實本身就是一種安全功能。第一，它讓使用者可以做真正的風險評估——知道 VM 保護的是 host，不是你餵進去的東西。第二，它避免了過度承諾導致的錯誤安全感。在一個所有 coding agent 都用「我們重視你的安全」這種模糊話術的市場裡，直接列出「❌ 不保護」清單不是美德——是戰術。工程師對說實話的工具，信任度遠高於對說「我們在乎你的隱私」的工具。

三、但「自己的機器」的代價是什麼？

Agent 在 VM 內有 root、可以 apt install、可以開 port、可以跑任意 process——這給了 agent 極大的自由度，但也意味著你必須信任 agent 不會在 VM 內挖礦、發送垃圾流量、當跳板。

clawk 的安全模型把問題從「信任 agent 不碰你的主機」變成「信任 agent 不在 VM 內做壞事」。這是一個比較小的信任範圍——但不是零。VM 內的惡意行為雖然不會直接汙染 host，但仍有幾個現實風險。第一，如果 agent 被 prompt injection 攻擊，它在 VM 內的行為仍然可以造成實質傷害——例如 commit 惡意程式碼、推送後門到你掛載的 repo。clawk 的 README 也明確說了這點：worktrees 可寫，agent 可以 commit 壞程式碼。第二，網路白名單是好的起點，但實際開發中你幾乎一定會開放某些 hostname（npm registry、PyPI、GitHub API），而這些合法的出口可以被濫用來傳輸資料。第三，hypervisor escapes 雖然機率低，但一旦發生，VM 隔離就歸零了——而 clawk 明確表示它不在此之上增加防禦。

我的立場是：這些風險是真實的，但 clawk 的取捨是對的。把信任範圍從「整台主機」縮小到「一台可拋棄的 VM」是一個巨大的進步。那些說「VM 隔離不夠、應該再加一層」的人，大部分並沒有在星期二下午真的幫 agent 設定過任何隔離環境。完美主義是務實主義的敵人。一台你實際會用的 VM，比一個你永遠不會設定的理論上完美的 sandbox，安全一萬倍。

clawk v0.2.0 以經把正確的事做到了「能用」的等級。剩下的是把那個「網路白名單預設 deny-all」變成沒有人會想去關掉的設定，把「30 分鐘自動停止」變成沒有人會覺得太短的時間，把「你的金鑰沒進 VM」變成所有 coding agent 工具的及格線。這些不是技術問題——是 UX 問題。而 clawk 做的最好的一件事，就是它知道自己是 UX 工具，不是資安論文。

城武的未解檔案——每個人都在爭論用 Firecracker 還是 gVisor 比較安全的時候，clawk 做了一件更難的事：讓那些不會爭論這些的人，也開始用 VM 隔離了。