Show HN：Clawk——给编码代理一个可丢弃的 Linux VM，而不是你的笔记本

为什么选 VM 而不是容器或单独用户

• 许多人认为容器共享主机内核，并且很大程度上依赖其正确性；VM 提供了更小、更清晰的隔离边界。
• 反方观点：如果容器配置得当，任何逃逸仍然是内核漏洞；有些人认为容器“已经足够好”，尤其是在额外加固之后（gVisor、Firecracker、Kata、eBPF）。
• 使用一个单独的非 sudo 用户被认为是最简单、最便携的方案，但也有人指出，这仍然共享主机包、守护进程和世界可读文件，而且很容易配置错误。
• 还有人更喜欢 VM，因为它们表现得像“真正的 Linux 机器”，Docker、Kubernetes 等都能自然运行，避免了 Docker-in-Docker 的变通做法。

安全性与威胁模型

• 关切不仅仅是“避免 rm -rf /”：
  • 通过 npm/pip/cargo 和不受信任的仓库进行供应链攻击。
  • 提示注入让代理执行提权或利用 LPE 漏洞。
  • 代理安装恶意包或滥用本地服务。
• 一些用户把自己的世界分成可信主机（只装发行版包）和用于其他一切的可丢弃 VM。
• 也有人认为，如果你并不假设代理是恶意的，那么 VM 就过于重了；他们更偏好更简单的用户或容器隔离。
• 也有人承认 VM 可能被逃逸；大家强调要保持内核更新。

网络与防火墙控制

• 一些工具专注于严格的网络允许列表、按域名或按协议感知的策略，以及应用层代理。
• 一种实现使用用户空间网络代理（例如 gvproxy），在其中终止访客连接并重新拨号到主机套接字，并在那里应用允许列表。
• 在 Linux 上，TAP 设备可能仍然需要 root，但过滤逻辑可以留在用户空间。
• 还有人尝试用 eBPF、nftables 或 MITM 代理来控制出站流量并保护密钥。

其他沙箱方案

• 讨论了广泛的选项：
  • 完整 VM（Firecracker、KVM、QEMU、Nix microVMs、incus、quickemu、Vagrant）。
  • 容器和 nspawn（Docker、Podman、systemd-nspawn、LXC）。
  • “几乎是容器”的方案和命名空间（bubblewrap、Landlock、Firejail、基于 bwrap 的工具）。
  • 远程 CI/开发平台和云沙箱（各种托管服务，其中一些支持 macOS）。
• 多个项目强调：声明式配置、按项目沙箱、密钥控制、快照/回滚、diff/apply 工作流、MCP 集成，以及凭证注入。

本地 vs 云端沙箱

• 有些人更喜欢本地 VM，因为它“本地优先”、符合公司政策，而且对第三方信任更低。
• 另一些人更偏好远程沙箱，这样笔记本可以休眠而代理继续运行，并且让代理与个人机器空气隔离。
• 也有人讨论购买一台专用开发盒（例如 Mac mini）的成本问题。

性能与易用性

• 在 macOS 上，据说文件 I/O 和进程监督开销会拖慢代理工作负载；把代理运行在 Linux VM 中可能会快得多。
• 有人强调命名空间沙箱可以瞬间启动，比完整 VM 或容器更轻量。
• 常见的可用性需求包括：多仓库工作区、持久历史记录、网络范围控制、更容易复用认证，以及从工具中干净退出。

怀疑与元讨论

• 许多人指出有“几十个”重叠项目；一些人认为这是不必要地重复造轮子，另一些人则认为这是健康的实验以及对代码完全掌控的需求。
• 批评主要集中在缺少更高层的部分：策略引擎、配置管理、回滚策略、动态凭证管理和服务代理。
• 大家对一个集成的“代理平台”很感兴趣，在那里沙箱、策略、密钥和可观测性都是一等公民，而不只是又一个裸沙箱。