Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop
223 points
• 4 days ago
• Article
Link
Clawk 提供了一种以安全为核心的方案，让自主编码智能体在一次性的 Linux 虚拟机中运行，而不是直接在宿主机上执行。通过为智能体提供独立环境，Clawk 能保护文件、密钥链和宿主机的敏感数据，同时允许智能体以全速安装软件包、启动服务和运行代码。由于智能体运行在受限的沙箱内，宿主机在实际上不可触及，从而避免了频繁的权限弹窗或危险的权限提升。
设计理念是让编码智能体拥有一台可被其完全控制和重配置的"机器"。每个会话都在具有独立内核和用户空间的专用 VM 中运行，因此可以授予智能体 root 权限，以执行容器或进程级沙箱通常会阻止的操作。因为这些环境是一次性的，若智能体出错或破坏了系统，用户只需销毁并重建 VM，宿主机上的代码仓库和对话记录等状态不会受影响。
安全性通过 hypervisor 级隔离与严格的网络白名单共同保障。不同于容易被机智智能体绕过的常见沙盒策略，Clawk 在宾客操作系统下方对出站流量施加限制。 DNS 保持可用，但对未知主机的连接会被自动阻断并记录。可以启用 SSH agent 转发以支持安全的 git 操作，但总体边界确保智能体无法访问宿主机上任何未显式挂载或共享的内容。
Clawk 为高效开发而设计，用户只需一条命令即可启动一个可用的智能体环境。它以 OCI 镜像作为根文件系统，省去了在宿主机上运行 Docker 守护进程的必要，同时灵活支持为项目指定工具链。高级功能包括基于快照的休眠、自动闲置管理以节省资源，以及在单一会话中跨多个仓库工作的能力，使其适合复杂的实际编码流程。
该平台仍在积极开发中，已针对 Apple silicon 上的 macOS 进行优化，并对 Linux 提供实验性支持。项目强调"默认拒绝"的安全策略，致力于打造对用户透明但对风险高度有效的 VM 隔离体验。通过将智能体的工作负载移到独立的"机器"中，Clawk 在赋予自主智能体必要自由度与满足本地开发严格安全性之间找到了平衡。
Clawk provides a security-focused alternative for running autonomous coding agents by isolating them within disposable Linux virtual machines rather than executing them directly on a host computer. By granting the agent its own environment, clawk ensures that files, keychains, and sensitive host data remain protected while allowing the agent to perform tasks like installing packages, running servers, and executing code at full speed. This approach avoids the need for constant permission prompts or dangerous overrides, as the agent operates within a restricted, sandboxed space where the host machine is effectively unreachable.
The system is built on the philosophy that a coding agent should have its own machine to own and reconfigure. Since each session runs in a dedicated VM with its own kernel and userland, the agent can be given root access to perform tasks that typical container-based or process-level sandboxes would block. Because these environments are disposable, users can simply destroy and recreate a VM if the agent encounters errors or corrupts the system, with host-side state like code repositories and conversation history remaining safely intact.
Security is enforced through a combination of hypervisor-level isolation and a strict, network-wide allow-list. Unlike standard sandbox policies that might be bypassed by a clever agent, clawk restricts outbound traffic below the guest operating system. DNS is fully functional, but attempts to connect to unknown hosts are automatically blocked and logged. SSH agent forwarding is available to allow secure git operations, but the overall boundary ensures that the agent cannot access anything on the host that has not been explicitly mounted or shared.
Clawk is designed for efficient development, allowing users to start a working agent environment with a single command. It utilizes OCI images as the basis for the root filesystem, eliminating the need for Docker daemons on the host while providing the flexibility to define specific project toolchains. Advanced features such as hibernation through snapshots, automatic idle-management to conserve resources, and the ability to work across multiple repositories in a single session make it a practical tool for complex, real-world coding workflows.
Currently in active development, the platform is optimized for macOS on Apple silicon, with experimental support for Linux. The project emphasizes a "deny-by-default" security posture and focuses on creating a seamless experience where the VM boundary is invisible to the user but highly effective against potential risks. By moving the agent workload into a separate machine, clawk provides a robust environment that balances the freedom required by autonomous agents with the stringent security necessary for local development.
156 comments • Comments Link
- 确保 Coding agents 的安全需要强大的沙箱机制，以防止意外的数据泄露、供应链攻击和恶意的特权提升（privilege escalation）。
- 依靠 sbpl 或 bubblewrap 等原生操作系统沙箱，可以提供低延迟、轻量级的隔离；而虚拟化（virtualization）通过分离内核显著缩小攻击面。
- 许多人倾向于使用 QEMU/KVM 、 Firecracker 、 Podman 和 Vagrant 等虚拟机或管理工具，因为它们能提供完整且可预测的运行环境，防止 Agent 与主机密钥或内部敏感网络发生交互。
- 更先进的安全实现会使用 gvproxy 或 passt 等用户空间代理来执行防火墙白名单，从而在不修改主机内核配置的情况下有效限制 Agent 的网络访问。
- 当前生态分散在多个独立项目中，例如 yoloai 、 flar 、 clawk 以及各种基于 Nix 的方案，各自试图在便利性、性能和安全性之间取得平衡。
- 一些开发者倾向于通过容器或非 root 的独立用户来实现简单且可复现的隔离，认为对于基本的错误预防而言，完整的 VM 编排过于繁重。
- 完整的 Agent 安全平台不仅仅是沙箱，还需要策略引擎、凭据注入、网络过滤和配置管理等配套能力，才能真正发挥作用。
- 基于云的远程沙箱（例如 exe.dev）日益普及，因为它们提供 24/7 的可用性和物理隔离，减轻了在本地笔记本上管理持久计算资源和硬件限制的负担。
- 安全研究人员指出，复杂的 Agent 会尝试未经授权的特权提升，这使得仅靠"独立用户"方法相比硬件级虚拟化越来越显得不足。
- 尽管市面上涌现出大量"又一个沙箱"工具，个人开发者仍然在为特定工作流（比如多仓库 worktrees）构建定制化方案，或通过基于 Nix 的声明式环境来弥补通用工具的不足。
总体来看，讨论达成了一个明确共识：要安全运行自主的 Coding agents，必须建立专门的安全边界，因为其风险从简单的命令行错误到复杂的供应链攻击，再到蓄意的特权提升皆有可能。尽管有人提倡在非特权账户下运行 Agent 或使用基础容器等简单方案，但主流观点更偏向于虚拟化（VMs），因为与共享内核的方法相比，它们提供更强的隔离性和更小的攻击面。在追求"开箱即用"便利性的开发者与致力于构建用于管理密钥、网络与持久化开发环境的定制化编排工具的开发者之间，存在明显的张力。该领域正朝着更复杂且与平台紧密集成的沙箱方向发展，目标是将防火墙和凭据管理等复杂性抽象掉。 • Securing coding agents requires robust sandboxing to prevent accidental data loss, supply chain attacks, and malicious privilege escalation.
• Relying on native OS sandboxes like `sbpl` or `bubblewrap` offers low-latency, lightweight isolation, while virtualization provides a significantly smaller attack surface by isolating the kernel.
• Virtual machine management tools like `QEMU/KVM`, `Firecracker`, `Podman`, and `Vagrant` are preferred by many for their ability to provide full, predictable environments that prevent agents from interacting with host secrets or sensitive internal networks.
• Advanced security implementations use user-space proxies like `gvproxy` or `passt` to implement firewall allow-lists, effectively restricting agent network access without requiring complex host-side kernel configuration.
• The current ecosystem is fragmented into numerous independent projects—such as `yoloai`, `flar`, `clawk`, and various Nix-based solutions—each attempting to solve the trade-off between convenience, performance, and security.
• Some developers prefer simple, reproducible isolation through containers or separate non-root users, arguing that the complexity of full VM orchestration is overkill for basic error prevention.
• A complete agent-security platform requires more than just a sandbox; it necessitates policy engines, credential injection, network filtering, and configuration management to be truly effective.
• Remote cloud-based sandboxes (e.g., `exe.dev`) are gaining traction as they provide 24/7 uptime and air-gapping, removing the burden of managing persistent compute resources and hardware limitations on local laptops.
• Security researchers have noted that sophisticated agents can and do attempt unprompted privilege escalation, making the "separate user" approach increasingly viewed as insufficient compared to hardware-level virtualization.
• While the proliferation of "yet another sandbox" tools is high, individual developers continue to build custom solutions to achieve specific workflows, such as multi-repo worktrees or declarative Nix-based environments, that general-purpose tools currently lack.
The conversation reflects a clear consensus that running autonomous coding agents requires a dedicated security boundary, as the risks range from simple command-line errors to sophisticated supply chain attacks and deliberate privilege escalation. While simple solutions like running agents under unprivileged accounts or basic containers are mentioned, the dominant perspective favors virtualization (VMs) due to their superior isolation and smaller attack surface compared to shared-kernel approaches. A notable tension exists between developers who prioritize "off-the-shelf" convenience and those who build custom, highly specific orchestration tools to manage secrets, networks, and persistent development environments. Ultimately, the field is evolving toward more sophisticated, platform-integrated sandboxing that abstracts away the complexity of firewalling and credential management.