Show HN: Clawk – Dê aos agentes de programação uma VM Linux descartável, não o seu laptop

Por que VMs em vez de contêineres ou usuários separados

• Muitos argumentam que contêineres compartilham o kernel do host e dependem fortemente da sua correção; VMs oferecem uma fronteira de isolamento menor e mais clara.
• Contra-argumento: se os contêineres forem configurados corretamente, qualquer breakout ainda é um bug do kernel; alguns os consideram “bons o suficiente”, especialmente com reforço extra (gVisor, Firecracker, Kata, eBPF).
• Usar um usuário separado sem sudo é proposto como a opção mais simples e portátil, mas outros observam que isso ainda compartilha pacotes do host, daemons e arquivos legíveis por todos, além de ser fácil de configurar errado.
• Alguns preferem VMs porque elas se comportam como “caixas Linux de verdade”, onde Docker, Kubernetes etc. rodam naturalmente, evitando gambiarras de Docker-in-Docker.

Segurança e modelos de ameaça

• As preocupações vão além de “evitar rm -rf /”:
  • Ataques à cadeia de suprimentos via npm/pip/cargo e repositórios não confiáveis.
  • Prompt injection fazendo agentes executarem escalada de privilégio ou explorarem LPEs.
  • Agentes instalando pacotes hostis ou abusando de serviços locais.
• Alguns usuários dividem seu mundo em um host confiável (apenas pacotes da distribuição) e VMs descartáveis para todo o resto.
• Outros acham que VMs são exagero se você não assume um agente hostil; eles preferem um isolamento mais simples por usuário ou contêiner.
• Também se reconhece que VMs podem ser escapadas; as pessoas enfatizam manter os kernels atualizados.

Controles de rede e firewall

• Várias ferramentas focam em listas de अनुमति estritas de rede, políticas por domínio ou conscientes de protocolo, e proxies no nível da aplicação.
• Uma implementação usa um proxy de rede em espaço de usuário (por exemplo, gvproxy) que termina conexões do convidado e refaz a conexão em sockets do host, aplicando ali uma lista de अनुमति.
• No Linux, dispositivos TAP ainda podem exigir root, mas a lógica de filtragem pode permanecer em espaço de usuário.
• Outros experimentam eBPF, nftables ou proxies MITM para controlar o tráfego de saída e proteger segredos.

Abordagens alternativas de sandboxing

• Ampla variedade de opções foi discutida:
  • VMs completas (Firecracker, KVM, QEMU, microVMs Nix, incus, quickemu, Vagrant).
  • Contêineres e nspawn (Docker, Podman, systemd-nspawn, LXC).
  • “Quase contêineres” e namespaces (bubblewrap, Landlock, Firejail, ferramentas baseadas em bwrap).
  • Plataformas remotas de CI/dev e sandboxes na nuvem (várias ofertas hospedadas, algumas com macOS).
• Vários projetos enfatizam: configuração declarativa, sandboxes por projeto, controle de segredos, snapshot/rollback, fluxos diff/apply, integração com MCP e injeção de credenciais.

Sandboxes locais vs na nuvem

• Alguns preferem VMs locais por “local-first”, conformidade com políticas da empresa e menor confiança em terceiros.
• Outros preferem sandboxes remotas para que o laptop possa dormir enquanto os agentes continuam executando, e para manter os agentes isolados das máquinas pessoais.
• O custo em relação a ter uma máquina de desenvolvimento dedicada (por exemplo, um Mac mini) é debatido.

Desempenho e ergonomia

• No macOS, o overhead de E/S de arquivos e supervisão de processos é dito desacelerar cargas de trabalho de agentes; executar agentes dentro de VMs Linux pode ser significativamente mais rápido.
• Alguns destacam sandboxes de namespace de início instantâneo como mais leves que VMs completas ou contêineres.
• Necessidades comuns de usabilidade: espaços de trabalho com múltiplos repositórios, histórico persistente, escopo de rede, reutilização de autenticação mais fácil e ejetar-se limpo da ferramenta.

Ceticismo e discussão meta

• Muitos observam que existem “dezenas” de projetos sobrepostos; alguns veem isso como reinvenção desnecessária da roda, outros como experimentação saudável e desejo de ter propriedade total do código.
• As críticas se concentram em peças de nível mais alto ausentes: mecanismos de política, gestão de configuração, estratégias de rollback, gestão dinâmica de credenciais e proxies de serviço.
• Há interesse em uma “plataforma de agentes” integrada, em que sandboxing, política, segredos e observabilidade sejam todos de primeira classe, em vez de apenas mais um sandbox cru.