Clawk: 為 AI 編碼代理提供的拋棄式 Linux VM

Clawk 是一款旨在為 AI 編碼代理提供專屬拋棄式 Linux 虛擬機器 (VM) 的工具，消除了直接在主機筆記型電腦上執行自主代理的風險。透過將代理隔離在具有獨立核心的單獨機器中，Clawk 確保代理無法存取主機的檔案系統、鑰匙圈或敏感的系統檔案，除非明確共享。

關鍵特性與能力

Clawk 允許編碼代理在受控環境中以完全的自主性進行操作——安裝套件、執行伺服器以及執行建置。

隔離與安全性

• Hypervisor 層級邊界：與程序層級的沙箱不同，Clawk 使用獨立的 Linux 核心。主機檔案系統並非透過拒絕規則來隱藏，而是根本沒有掛載。
• 網路允許清單：預設情況下，所有傳出流量都會被拒絕。每個沙箱都有其專屬的 DNS 感知允許清單，確保代理只能存取經核准的伺服器（例如 GitHub, npm, PyPI）。
• 秘密保護：SSH keys 與其他敏感憑證保留在主機上。Clawk 使用 ssh-agent forwarding 來允許代理執行 git push 操作，而無需讓實際的 keys 進入 VM。
• 拋棄式生命週期：如果代理損壞或搞砸了 VM，可以使用 clawk destroy && clawk 立即銷毀並重建，同時專案儲存庫與代理對話歷史紀錄仍保留在主機上。

工作流整合

• 單一指令設定：在專案目錄中執行 clawk 會自動啟動沙箱並附加一個代理（例如 Claude Code 或 Codex）。
• OCI 映像檔支援：任何 OCI 映像檔都可以作為 rootfs，允許使用者透過 clawk.mod 設定檔來定義專案所需的精確工具鏈。
• Ticket Mode：對於跨越多個儲存庫的任務，Clawk 可以建立單個沙箱，並為每個儲存庫建立一個 git worktree，從而協調多個專案的變更並開啟跨連結的 PR。
• 狀態持久化：代理對話與記憶體是透過主機掛載的，這意味著使用 --resume 旗標時，重建的 VM 會從上次會話結束的地方精確地繼續。

技術架構

Clawk 透過建立每個沙箱專屬的守護程序 (daemon) 來運作，該程序負責管理 VM 的生命週期與網路。

• Hypervisor：在 macOS 上，它利用 Apple 的 Virtualization.framework；在 Linux 上，它使用 firecracker（目前為實驗性質）。
• Networking：該守護程序實作了使用者空間的 TCP/IP 堆疊 (gvproxy)。這使得網路過濾器可以在客體 OS 之下運作，這意味著即使是 VM 內部的 root 使用者也無法重新配置防火牆。
• 磁碟管理：OCI 映像檔會被拉取並扁平化為 ext4 磁碟。為了節省空間，Clawk 使用寫入時複製 (copy-on-write) 克隆 (APFS clonefile 在 macOS 上)，因此來自相同映像檔的多個沙箱僅會針對客體的寫入產生額外的空間消耗。
• Access：客體內部沒有 sshd 或 cloud-init。存取是透過 vsock bridge 連結到客體內的 pty-agent。

與其他沙箱化方法的比較

| 方法 | 隔離層級 | 設定開銷 | 主機風險 | | :--- | :--- | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :---ization/\n\n| Method | Isolation Level | Setup Overhead | Host Risk |\n| :--- | :--- | :--- | :--- |\n| Local Process | None | Low | High |\n| Containers/Devcontainers | Shared Kernel | Low | Medium (Kernel bugs/socket mounts) |\n| C-level Sandboxes | Process-level | Low | Medium (Policy mistakes) |\n| Clawk (VMs) | Separate Kernel | Low | Low |\n\n## 社群洞察與替代方案

開發者之間的討論突顯了「代理化」基礎設施日益增長的趨勢。雖然有些使用者建議單獨的 OS 使用者或 Podman 容器對於基礎隔離已足夠，但其他人則強調，對於需要原生依賴項或巢狀虛擬化（例如在沙箱中執行 Docker）的工作負載，完整的 VM 是必要的。

社群討論中提到了幾個替代專案，包括：

• yoloai: 一種類似的沙箱化方法，支援多種後端（Docker, gVisor, Firecracker）。
• flar: 一種基於命名空間的方法，透過 bubblewraps 代理，其啟動速度比 VM 更快。
• katsuobushi: 一種基於 Nix 的沙箱，利用 microvm.nix 進行宣告式配置。
• AgentCage: 一款工具，提供容器與 VM 的選擇，並附帶 MITM 代理進行監控。

系統需求與限制

• Platform Support：完整支援需要 Apple silicon 上的 macOS 14+\n- Hardware Gating：巢狀虛擬化（在 VM 內執行 Docker/Kubernetes）是一項需自行選擇的功能，需要特定的硬體與客體核心覆蓋。\n- Security Limits：Clawk 不保護免於代理提交到儲存庫中的惡意代碼，也不保護免於 hypervisor escapes。建議使用者在審查所有代理生成的 commits 時，應像審查陌生人的 PR 一樣進行。