Conecta tus propios agentes ACP a Ghosty Teams fácilmente

Ghosty Teams habla ACP (Agent Client Protocol), así que puedes conectarle un agente que corra en tu propia infraestructura y darle un @handle en los hilos de tu equipo. El agente usa su disco y su terminal, no los de nadie más, y tu código nunca sale de ahí.

Aquí lo montamos de cero con GhostyCode dentro de una microVM de EasyBits. Ocho pasos, todo con curl, sin SSH y sin entrar a la caja.

Necesitas una cuenta de Ghosty Teams, Node y una llave de EasyBits de Dashboard → Developer.

Paso 0 · Variables

Paso 1 · Crear la caja

Son 2 vCPU, 2 GB y disco propio, aislada por el hipervisor.

Paso 2 · Darle vida

Nace con 30 minutos. Extiéndela antes de invertirle trabajo:

Comprueba que expiresAt se movió cuatro horas. Si sigue en los 30 minutos originales, la caja no aceptó la extensión y mejor saberlo ahora que a media instalación.

Paso 3 · Instalar el agente

/exec corre comandos dentro de la caja por REST. Sin llave ed25519, sin túnel:

Ese filtro de python3 al final vale la pena en todos los /exec: la respuesta es un JSON con el stdout adentro, y sin desescaparlo lees la salida en una sola línea con \n literales.

Necesitas GhostyCode 0.0.20 o superior: es la versión donde ghosty serve sirve ACP por red sin banderas.

Paso 4 · Apuntar el LLM

provider = "openai" no significa que hables con OpenAI: es la ruta genérica de ghosty para cualquier endpoint que hable el dialecto de su API. Quien contesta es el gateway de EasyBits, y sirve DeepSeek. La llave se queda dentro de la caja; tu chat nunca la ve.

Fíjate en el model repetido. El de la raíz lo usa la TUI; el de la tabla del provider es el que viaja en la petición. Con solo el primero, ghosty manda su default (gpt-5.6) y el gateway lo rebota con Invalid request (400) — un error que parece de la caja y es del nombre del modelo.

Paso 5 · Crear el workspace

Ghosty Teams abre la sesión ACP con cwd: /data/work. Ese directorio es la casa del agente: todo lo que quede fuera lo rechaza con path escapes workspace, aunque el proceso corra en otro lado. Créalo y pon ahí tu proyecto:

Paso 6 · Levantar el servidor ACP

En background, con /bg, y con un token que eliges tú:

ghosty serve a secas publica ACP en /acp, el runtime en /v1/* y GET /health, y dentro de un contenedor o microVM se enlaza a 0.0.0.0 por su cuenta — lo detecta por /.dockerenv, el cgroup o el DMI del hipervisor. En tu laptop sigue en loopback, que es como debe ser.

Elige el token tú: sin --auth-token, ghosty genera uno que no imprime, y entonces todo cliente remoto recibe un 401 que parece un bug del servidor. Y sin ninguna credencial —con --insecure— lo único que protege tu caja es que nadie adivine su URL.

Paso 7 · Exponer el puerto

Te devuelve una URL https://sb-<uuid>-7878.sandboxes.easybits.cloud, y esa misma sirve wss:// sin nada extra. Compruébala antes de ir a Teams:

/health queda abierto a propósito: es lo que consulta quien da de alta la caja. Todo lo demás exige el bearer.

No pruebes /acp con curl. Contesta 406 client must accept text/event-stream porque curl no hace el upgrade a WebSocket, y ese error manda a buscar el problema donde no está.

Paso 8 · Conectarlo a Ghosty Teams

En Ajustes → Agentes → Agregar agente → Por ACP, pega la URL con esquema de socket y la ruta del protocolo:

Debajo hay un campo para el token: pega ahí el $ACP_TOKEN del paso 6. Va en ese campo y no en la URL — Teams lo manda como cabecera Authorization: Bearer, y una URL acaba en los access logs de cualquier proxy del camino.

Dale Probar. Teams abre el WebSocket y hace initialize, el mismo handshake del primer mensaje real, y te muestra lo que el agente responde de sí mismo: ghosty 0.0.20 · ACP v1. Ponle @handle, nombre visible y Agregar.

Si más adelante editas el agente, el campo del token nace vacío y vacío significa "déjalo como está". Escribe uno nuevo solo cuando quieras cambiarlo.

Ya puedes escribirle en cualquier hilo:

Lo que sigue viaja por el socket que abriste: el mensaje entra a tu microVM, el agente lee su propio disco y la respuesta vuelve al hilo, donde la ve tu equipo.

Lo que ganas al moverlo del editor al chat

ACP nació para que un editor lance un agente como proceso hijo y le hable por stdio. Cruzando la red esa relación padre-hijo desaparece, y con ella cambian tres cosas a mejor:

• Los permisos se aprueban en un hilo. ACP tiene session/request_permission: el agente se detiene y espera autorización antes de actuar. En un editor eso es un modal que solo tú ves; en un chat es asíncrono, lo ve el equipo y queda como bitácora.
• El agente conserva su terminal. Teams no declara clientCapabilities.fs ni .terminal, y en ACP omitirlas significa "no soportadas". El agente usa entonces su propio disco y su propia terminal — justo para lo que existe la microVM.
• Una caja por agente. Cada @handle puede apuntar a su propia máquina, con su repo, sus llaves y su modelo.

La caja duerme sola

Si nadie le escribe en cinco minutos, la microVM se congela. Escribes @caja otra vez y despierta en un par de segundos: Teams la revive antes de abrir el socket.

No tienes que hacer nada, ni pagar por una caja que nadie está usando.

Una caja por agente

El montaje se repite tantas veces como agentes quieras: cada @handle puede apuntar a su propia microVM, con su repo, su token y su modelo. La única parte que sigue siendo tuya es el POST del paso 1 — crearla la primera vez.