Tu agente de código, en una caja aparte y conectado a VS Code

Un agente de código corriendo en tu laptop tiene tu disco entero, tus llaves de SSH y tu sesión de npm. Funciona muy bien hasta el día que no.

La alternativa es darle su propia máquina: el agente vive en una microVM, con su disco y su red, y tú lo usas desde tu editor de siempre como si estuviera local. Se siente igual, pero cuando decide borrar algo, lo borra allá.

Vamos a montarlo completo. Necesitas una llave de Easybits y unos diez minutos.

Paso 1 · La caja

Una llamada, y tienes una microVM con goose dentro:

Guarda ese sandboxId: es la dirección de tu agente para todo lo que sigue.

Ese suspendOnIdle vale la pena: cuando la caja lleva un rato sin hacer nada, en vez de destruirse se duerme —snapshot de la VM entera— y despierta en menos de un segundo con todo su estado. Pagas por lo que usas sin perder el hilo de la conversación.

Paso 2 · Un secreto, antes de abrir nada

Aquí es donde conviene ir en el orden correcto, y ahora explico por qué.

goose habla ACP (Agent Client Protocol): JSON-RPC 2.0 sobre WebSocket, el protocolo que usan los editores para hablar con agentes externos. Su servidor se levanta así:

Y valida credencial contra la variable GOOSE_SERVER__SECRET_KEY. Si esa variable no existe, el servidor no arranca — a menos que le pases --dangerously-unauthenticated, que hace exactamente lo que su nombre promete.

Genera un token y déjalo puesto como servicio, para que sobreviva a un reinicio:

Anota ese $TOKEN. Lo vas a necesitar en el paso 4, y es el único momento en que lo ves.

Por qué antes de exponer el puerto: un endpoint abierto que ya funciona no vuelve a pedirte atención. Nosotros dejamos el nuestro días con --dangerously-unauthenticated mientras configurábamos, tan tranquilos, un token en el editor que del otro lado nadie estaba leyendo. Todo se veía correcto. Ponerlo primero cuesta un minuto; descubrirlo después cuesta la tarde.

Paso 3 · El puerto público

El proxy termina TLS y trabaja en capa 7, así que ese mismo host sirve https:// y wss:// sin que hagas nada más. Nada de túneles, ni cloudflared, ni tocar tu router.

Compruébalo antes de seguir. Sin credencial:

Ese 401 es la señal de que el paso 2 quedó bien. Si te responde otra cosa, arréglalo ahora.

Paso 4 · El puente hasta tu editor

Falta una pieza pequeña y es la que menos gente espera: tu editor no consume una URL. ACP asume agentes locales, así que el editor ejecuta un comando y le escribe JSON-RPC por la entrada estándar. La dirección wss:// perfectamente válida que acabas de conseguir no la puede usar ningún editor tal cual.

El puente traduce el cable —entrada/salida estándar de un lado, WebSocket del otro—. El nuestro se llama ghosty-acp: Node puro, sin dependencias, se ejecuta con npx y no hay nada que instalar.

En VS Code, esto va en tu settings.json:

Un par de aclaraciones útiles:

VS Code no trae ACP de fábrica. Microsoft estandarizó su modo agente sobre MCP y no ha adoptado ACP, así que hace falta una extensión de la comunidad — ACP Client es la más usada, y es la que define esa clave acp.agents. En Zed el soporte sí es nativo y la configuración es equivalente, bajo agent_servers.

El token va en env, nunca en args. Los argumentos de un proceso los lee cualquier otro proceso de tu máquina con un ps. Esto es una credencial de acceso a tu agente: trátala como tal.

Recarga la ventana, abre el panel del agente y elige mi-agente. Debería decir connected.

Paso 5 · La primera conversación

Escríbele cualquier cosa. Te va a contestar y, sobre todo, va a poder trabajar: tiene shell, disco y red propios dentro de la caja.

Y aquí el detalle que conviene entender desde el primer minuto: el agente edita lo que hay en la caja, no tu copia de trabajo.

Tu editor te va a mostrar la ruta de tu proyecto local en la cabecera de la sesión, porque es lo que él cree haber mandado. No es donde el agente está parado. Todo cliente ACP manda esa ruta al abrir sesión, el agente no tiene ese directorio, y el puente la reescribe al vuelo a una que sí existe allá (/root por defecto, o lo que pongas en GHOSTY_ACP_CWD). Te avisa cuando lo hace:

Para meterle tu código, lo natural es que él mismo lo clone —tiene red— o subirlo a la caja. No hay disco compartido, y esa es justamente la propiedad que fuiste a buscar.

Si algo no cuadra

El puente manda todo su diagnóstico a la salida de error, y ahí está el detalle bueno. La burbuja gris del editor suele decir menos de lo que parece:

Ese segundo caso merece una nota, porque el rótulo miente con mucha convicción: dice connect cuando el WebSocket ya estaba abierto y feliz. El error real venía dentro, en JSON-RPC:

Cuando algo falle en esta cadena, la pregunta útil no es "¿está bien la URL?" sino "¿en qué mensaje exacto falló?".

Lo que te queda montado

Un agente con su propia máquina, alcanzable desde tu editor, protegido por un token, que se duerme solo cuando no lo usas y despierta con su estado intacto. Nada corriendo en tu laptop más que un puente de veinte líneas.

Y el día que le pidas algo y salga mal, sale mal en su caja.