clawk

Um agente de programação só é útil quando você o deixa realmente fazer coisas: instalar pacotes, executar o código que escreve, iniciar servidores, usar a rede. Na sua própria máquina, isso deixa duas opções ruins. Você aprova cada comando (e fica de babá de um prompt a cada poucos segundos), ou executa --dangerously-skip-permissions e torce para que nada importante esteja a um rm -rf ou a um token vazado de distância.

clawk é uma terceira opção. Faça cd em um repositório, digite clawk, e o Claude Code (ou Codex, ou pi, ou um shell) estará trabalhando dentro de uma VM Linux descartável (seu código montado dentro, root no guest, sem prompts de permissão) enquanto seus arquivos, seu keychain e o resto da sua máquina permanecem fora de alcance. O agente ganha sua própria máquina em vez da sua.

_{Um comando para um agente funcional; uma tentativa de enviar dados para um servidor desconhecido, bloqueada pela lista de permissões de rede; clawk attach retoma a sessão depois.}

A fronteira não é uma regra em um prompt da qual o agente poderia ser convencido a desistir. É uma máquina separada, e as únicas aberturas são as que você montou. De um shell dentro de um sandbox:

$ curl https://tracker.evil.example   # not on the allow-list: blocked
curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused

$ cat ~/.ssh/id_rsa                   # your keys never entered the VM
cat: /home/agent/.ssh/id_rsa: No such file or directory

$ git push                            # ...yet this works: ssh-agent is forwarded
Enumerating objects: 5, done.

Para ser honesto sobre os limites, a lista de permissões bloqueia conexões a servidores desconhecidos, não aos que você permitiu: github.com é pré-permitido e o ssh-agent encaminhado pode fazer push, então trate qualquer coisa que o agente consiga ler como algo que ele poderia publicar. O modelo de segurança detalha isso.

E se o agente destruir a VM, execute clawk destroy && clawk: uma VM nova, o mesmo repositório, e --resume restaura a conversa.

[!IMPORTANT] Pré-1.0 e evoluindo rápido. Espere mudanças que quebram compatibilidade entre versões e ocasionais arestas ásperas; as coisas podem e vão quebrar. Por favor, abra issues; esse feedback está moldando a 1.0.

Destaques

• Deixe o agente fazer qualquer coisa. Ele roda em uma VM descartável com uma rede restrita, então rm -rf, instalações de pacotes e código não confiável não conseguem alcançar seu host, seus arquivos ou qualquer coisa que você não compartilhou explicitamente.
• Trabalhando em um único comando. Faça cd em um repositório e execute clawk. Sem Dockerfile, devcontainer ou arquivo de configuração. O primeiro boot constrói um rootfs a partir da sua imagem; cada boot seguinte leva segundos.
• Quebre sem perder nada. Destrua e recrie livremente; seu código e as conversas do agente vivem no host. Apenas o disco descartável da VM é perdido.
• Uma máquina Linux de verdade, seu toolchain. Qualquer imagem OCI é o rootfs: um SO completo com exatamente as ferramentas que seu projeto precisa. Nenhum daemon Docker necessário.
• Segredos ficam na sua máquina. O tráfego de saída é permitido por lista e seu ssh-agent é encaminhado, então git push funciona sem que chaves entrem na VM.
• Um sandbox por projeto ou ticket. Execute vários ao mesmo tempo; tickets multi-repo recebem um git worktree por repositório com PRs coordenados. VMs ociosas liberam memória automaticamente e suspendem para o disco, então um sandbox esquecido custa (quase) nada.

Por que uma VM?

clawk é um ambiente local de propósito geral para agentes de codificação autônomos. A VM é o ponto central: é uma máquina inteira que o agente pode possuir, não um processo envolto em políticas na máquina que você está usando.

• Um kernel separado. O guest roda seu próprio kernel Linux, então o sistema de arquivos do host não está escondido atrás de regras de negação; ele nunca foi montado.
• Um ambiente Linux convencional. Kernel padrão, userland padrão, expectativas no formato de /dev/kvm, então as ferramentas se comportam como suas docs dizem, sem surpresas de filtro de syscalls.
• Root no guest. Instale pacotes do sistema, edite /etc, carregue um módulo, faça bind em uma porta privilegiada. É a caixa do agente para reconfigurar.
• Um ciclo de vida descartável. Barato de quebrar e rápido de recriar; uma VM destruída está a um clawk destroy && clawk de distância, com seu repositório e conversas intactos no host.
• Separação mais forte do host. O isolamento repousa na fronteira do hypervisor em vez de acertar exatamente uma política de sandbox de processo.

Essa combinação executa cargas de trabalho com as quais um sandbox de processo restrito tende a brigar com você:

• instalar pacotes e dependências nativas;
• executar serviços em segundo plano (bancos de dados, filas, servidores de desenvolvimento);
• executar builds e testes não confiáveis em velocidade máxima;
• usar ferramentas Linux de nível de sistema que esperam uma máquina real;
• e, com um kernel guest habilitado para KVM em hardware suportado, fluxos de trabalho de desenvolvimento com contêineres e Kubernetes, como Docker ou Kind rodando dentro do sandbox. Isso é opt-in e condicionado ao hardware; veja Images para os requisitos exatos.

Nada disso é o produto; clawk é para trabalho local com agentes em geral. Docker e Kubernetes são apenas o exemplo mais evidente de "precisa de uma máquina real, não de um processo em sandbox."

Instalação

Requer macOS 14+ em Apple silicon. (Linux é suportado via firecracker e atualmente experimental — comece com docs/linux-quickstart.md, que cobre a configuração, o fluxo de trabalho e as lacunas. Este README é focado em macOS.)

brew install clawkwork/tap/clawk

Do código-fonte (contribuidores, ou se você não usa Homebrew), requer Go 1.26+:

git clone https://github.com/clawkwork/clawk && cd clawk
make install