clawk — Dá um VM Linux Descartável ao Teu Coding Agent

Um coding agent que pode correr rm -rf / sem consequências. Esse é o nível de isolamento que o clawk traz: cada agente tem a sua própria máquina Linux descartável, e a tua fica intacta.

Usar coding agents como Claude Code ou Codex traz um dilema. Para serem úteis, precisam de instalar pacotes, correr código, iniciar servidores, usar a rede. Na tua máquina, as opções são duas: aprovar cada comando (e babysitar prompts de 5 em 5 segundos), ou ativar o --dangerously-skip-permissions e rezar para que nada importante esteja a um rm -rf ou um token vazado de distância.

O clawk é a terceira via. Criado por clawkwork, escrito em Go, disponível em github.com/clawkwork/clawk. A ideia é simples: em vez de pores o agente a correr no teu sistema, dás-lhe uma VM Linux inteira, descartável, com a rede controlada e o teu código montado lá dentro.

O que interessa aqui é como o clawk isola coding agents com VMs descartáveis, a diferença entre isolamento por VM e sandboxing por processo, o sistema de rede com allow-list por projeto, e o ciclo de vida de uma sandbox. - O que ainda falta para a versão 1.0

⬆ clawk a bootar uma VM e a fazer attach do Claude Code — um comando, zero babysitting

O Problema: Agentes Precisam de Liberdade, Tu Precisas de Controlo

Coding agents são ferramentas poderosas porque fazem coisas. Instalam dependências, escrevem ficheiros, correm testes, fazem commits, dão push. Mas essa autonomia é exatamente o que os torna perigosos no teu ambiente real.

As soluções existentes não são ideais:

• Containers (Docker, devcontainers) — partilham o kernel do host e um bug de escalamento pode expor tudo. Além disso, muitas configurações montam o socket do Docker, dando ao container controlo total sobre o daemon do host.
• Sandboxes a nível de OS (como o sandbox-runtime da Anthropic) — aplicam regras de processo na tua máquina real. Um erro de configuração e as tuas chaves SSH, keychain e tokens ficam expostos.
• Aprovar cada ação — derrota o propósito de ter um agente autónomo.

O clawk aborda o problema de raiz: o agente não está na tua máquina. Está noutra máquina.

O Que É o clawk, Exactamente

O clawk é uma CLI que cria VMs Linux descartáveis para coding agents. Funciona em macOS Apple Silicon (via Virtualization.framework) e experimentalmente em Linux (via Firecracker). Cada projeto tem a sua própria VM, isolada por hypervisor, com o código montado lá dentro e a rede filtrada por uma allow-list que nem o root do guest consegue alterar.

cd ~/code/meu-projeto
clawk                      # boot da VM + attach do Claude Code
clawk run shell            # ou: abre uma shell na mesma VM
clawk down                 # para a VM (repositório + estado do agente preservados)
clawk attach               # volta mais tarde — faz boot e reattach
clawk destroy              # remove a VM (conversas do agente ficam)

A barreira não é uma regra num prompt que o agente pode ser convencido a ignorar. É uma máquina separada. O que o agente vê é apenas o que tu montaste e permitiste na rede.

Porquê uma VM e Não um Container?

Esta é a decisão central do clawk e vale a pena perceber porquê.

Uma VM dá ao agente um sistema Linux standard: kernel normal, userland normal, /dev/kvm se o hardware suportar. Pode instalar pacotes, editar /etc, carregar módulos, fazer bind a portas privilegiadas. Coisas que um container restrito muitas vezes não deixa fazer.

E quando o agente parte tudo? clawk destroy && clawk — VM nova, repositório intacto, conversas preservadas.

Rede Bloqueada por Defeito

O tráfego de saída está negado por omissão. Cada sandbox tem a sua própria allow-list. DNS resolve tudo, mas TCP, UDP (incluindo QUIC) e ICMP para hosts não listados são recusados.

Registos comuns (npm, PyPI, crates.io, GitHub, Anthropic) vêm pré-autorizados. O filtro é DNS-aware: se permitires example.com, funciona mesmo quando os IPs mudam.

clawk network allow meu-projeto api.stripe.com
clawk network denials meu-projeto    # o que o agente tentou e foi bloqueado
clawk forward add meu-projeto 3000   # localhost:3000 → servidor dev no guest

As negações são registadas com o hostname que o guest resolveu. O resultado é um log do que o agente tentou alcançar — útil para ajustares a lista sem adivinhares.

Ciclo de Vida: Partir sem Medo

A regra de persistência do clawk é simples: a VM é descartável, tudo o que importa vive no host.

                    clawk down    clawk destroy
Repo (commits)                     
Estado do agente                   
Disco da VM            ❌            ❌

O estado do agente (conversas do Claude, memória, projetos) fica montado no host em ~/.clawk/namespaces/default/state/<nome>/. Quando recrias a sandbox, o --resume recupera a conversa anterior.

Há ainda suporte a snapshot: clawk snapshot salva a memória da VM para disco. Quando fazes resume, a VM volta exatamente ao estado anterior — processos em background, servidores dev, tudo.

Configuração com clawk.mod

Quando um projeto precisa de mais que os defaults, cria-se um clawk.mod:

sandbox meu-projeto (
    vm (
        cpu    4
        memory 8GiB
        image  golang:1.25     # qualquer imagem OCI serve de rootfs
    )
    network ( allow api.stripe.com )
    forwards ( 3000 )
    env ( DATABASE_URL )       # só os nomes; valores vêm da tua shell
    on create ( "go mod download" )
    agent (
        instructions "Ask before running destructive commands."
    )
)

Sem ficheiro Docker, sem devcontainer.json, sem configuração extra. Qualquer imagem OCI que uses no Docker funciona aqui.

Ticket Mode: Vários Repos, Uma Sandbox

Trabalhas num ticket que abrange vários repositórios? O clawk work cria uma sandbox com uma git worktree por repo, em branches novas, e o clawk pr mais tarde abre PRs coordenados para o que mudou.

cd ~/code/meu-workspace      # contém um clawk.mod com a lista de repos
clawk work INFRA-123          # uma sandbox, worktree por repo, Claude attached
clawk pr INFRA-123            # push branches + PR por repo

Estado Actual e Limitações

O clawk está pré-1.0 e em desenvolvimento activo. Breaking changes são esperadas entre releases. O que deves saber:

• Só macOS Apple Silicon para uso diário. O suporte Linux via Firecracker é experimental (sem propagação live de worktrees, sem host-file push).
• Intel Macs e Windows — não suportados.
• Modelo de segurança — o que montares ou permitires na rede está exposto. O agente pode fazer commit de código malicioso ou dar push para qualquer repo que o teu ssh-agent consiga alcançar. Revê o que sai de uma sandbox como reverias o PR de um estranho.
• Pre-1.0 — nada está congelado até ao lançamento.

Conclusão

O clawk resolve um problema real de forma elegante. Em vez de tentar domar coding agents com políticas de processo, prompt engineering ou approval flows, dá-lhes o que eles precisam — uma máquina inteira — e mantém a tua separada.

A barreira é física (ou quase): um hypervisor, não uma rule list. O agente pode fazer o que quiser dentro da VM, e quando a parte, clawk destroy && clawk e está pronto outra vez.

Para quem usa coding agents no dia-a-dia e quer produtividade máxima sem comprometer a segurança da máquina, vale a pena experimentar. Especialmente o ticket mode, que fecha o ciclo multi-repo de uma forma que ainda não vi noutra ferramenta.

Recursos adicionais

• Repositório oficial clawk
• Documentação — Arquitetura
• Documentação — Segurança
• Documentação — Configuração clawk.mod
• Documentação — Modo Ticket