clawk

Un agente de programación solo es útil cuando le dejas realmente hacer cosas: instalar paquetes, ejecutar el código que escribe, iniciar servidores, usar la red. En tu propia máquina eso deja dos malas opciones. Apruebas cada comando (y atiendes un aviso cada pocos segundos), o ejecutas --dangerously-skip-permissions y esperas que nada importante esté a un rm -rf o a un token filtrado de distancia.

clawk es una tercera opción. Haz cd a un repositorio, escribe clawk, y Claude Code (o Codex, o pi, o un shell) estará trabajando dentro de una VM Linux desechable (tu código montado dentro, root en el invitado, sin avisos de permisos) mientras tus archivos, tu llavero y el resto de tu máquina quedan fuera de alcance. El agente obtiene su propia máquina en lugar de la tuya.

_{Un comando para tener un agente funcional; un intento de enviar datos a un servidor desconocido, bloqueado por la lista de permitidos de red; clawk attach reanuda la sesión más tarde.}

El límite no es una regla en un prompt de la que se pueda convencer al agente. Es una máquina separada, y las únicas aperturas son las que tú montaste. Desde un shell dentro de un 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 honestos sobre los límites, la lista de permitidos bloquea las conexiones a servidores desconocidos, no a los que has permitido: github.com está pre-permitido y el ssh-agent reenviado puede hacer push, así que trata cualquier cosa que el agente pueda leer como algo que podría publicar. El modelo de seguridad lo detalla.

Y si el agente destroza la VM, ejecuta clawk destroy && clawk: una VM nueva, el mismo repositorio, y --resume restaura la conversación.

[!IMPORTANT] Pre-1.0 y avanzando rápido. Espera cambios que rompan la compatibilidad entre versiones y algún que otro borde áspero; las cosas pueden y van a romperse. Por favor, abre issues; ese feedback está dando forma a la 1.0.

Aspectos destacados

• Deja que el agente haga cualquier cosa. Se ejecuta en una VM desechable con una red restringida, así que rm -rf, las instalaciones de paquetes y el código no confiable no pueden alcanzar tu host, tus archivos ni nada que no hayas compartido explícitamente.
• Trabajar con un solo comando. Haz cd a un repositorio y ejecuta clawk. Sin Dockerfile, devcontainer ni archivo de configuración. El primer arranque construye un rootfs a partir de tu imagen; cada arranque posterior tarda segundos.
• Rómpelo sin perder nada. Destruye y recrea libremente; tu código y las conversaciones del agente viven en el host. Solo se pierde el disco desechable de la VM.
• Una caja Linux real, tu toolchain. Cualquier imagen OCI es el rootfs: un SO completo con exactamente las herramientas que tu proyecto necesita. No se requiere demonio de Docker.
• Los secretos se quedan en tu máquina. El tráfico saliente está en la lista de permitidos y tu ssh-agent se reenvía, así que git push funciona sin que las claves entren en la VM.
• Un sandbox por proyecto o ticket. Ejecuta varios a la vez; los tickets multi-repositorio obtienen un git worktree por repositorio con PRs coordinados. Las VM inactivas liberan memoria automáticamente y se suspenden a disco, así que un sandbox olvidado cuesta (casi) nada.

¿Por qué una VM?

clawk es un entorno local de propósito general para agentes de codificación autónomos. La VM es el punto: es una máquina completa que el agente puede poseer, no un proceso envuelto en políticas sobre la que estás usando.

• Un kernel separado. El invitado ejecuta su propio kernel Linux, así que el sistema de archivos del host no está oculto tras reglas de denegación; nunca estuvo montado.
• Un entorno Linux convencional. Kernel estándar, userland estándar, expectativas con forma de /dev/kvm, así que las herramientas se comportan como dicen sus docs, sin sorpresas de filtrado de syscalls.
• Root en el invitado. Instala paquetes del sistema, edita /etc, carga un módulo, enlaza un puerto privilegiado. Es la caja del agente para reconfigurar.
• Un ciclo de vida desechable. Barato de romper y rápido de recrear; una VM destrozada está a un clawk destroy && clawk de distancia, con tu repositorio y conversaciones intactos en el host.
• Mayor separación del host. El aislamiento descansa en la frontera del hipervisor en lugar de acertar exactamente con una política de sandbox de procesos.

Esa combinación ejecuta cargas de trabajo con las que un sandbox de procesos restringido tiende a pelearse contigo:

• instalar paquetes y dependencias nativas;
• ejecutar servicios en segundo plano (bases de datos, colas, servidores de desarrollo);
• ejecutar builds y tests no confiables a plena velocidad;
• usar herramientas Linux a nivel de sistema que esperan una máquina real;
• y, con un kernel invitado habilitado para KVM en hardware compatible, flujos de trabajo de desarrollo de contenedores y Kubernetes como Docker o Kind ejecutándose dentro del sandbox. Esto es opcional y está condicionado al hardware; consulta Images para los requisitos exactos.

Nada de esto es el producto; clawk es para trabajo local con agentes en general. Docker y Kubernetes son solo el ejemplo más claro de "necesita una máquina real, no un proceso en sandbox."

Instalación

Requiere macOS 14+ en Apple silicon. (Linux es compatible vía firecracker y actualmente es experimental — empieza con docs/linux-quickstart.md, que cubre la configuración, el flujo de trabajo y las carencias. Este README está orientado primero a macOS.)

brew install clawkwork/tap/clawk

Desde el código fuente (colaboradores, o si no usas Homebrew), requiere Go 1.26+:

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