Rigs y recintos

Un rig es una máquina desechable que un agente dirige en tiempo real: un navegador, un escritorio Linux, un emulador de Android, un simulador de iOS o la máquina que hay detrás de un terminal con recinto. La mayoría de los rigs son VM; los simuladores móviles gestionados por el host son las excepciones explícitas. Esta página explica cada frontera y por qué las piezas tienen la forma que tienen. Para abrir uno, consulta Dar a un agente una máquina para probar; para los verbos, puertos y valores predeterminados exactos, consulta la referencia de rigs.

Por qué una VM y no un entorno aislado

El entorno aislado nativo envuelve un proceso en aislamiento de espacios de nombres: es real, pero comparte tu kernel y limita un proceso, no un ordenador. En el momento en que un agente necesita hacer clics por una aplicación de escritorio, renderizar una página en un navegador real o ejecutar experimentos con rm -rf en los que prefieres no pensar, la frontera honesta es una máquina: su propio kernel, su propio disco, su propia pila de red.

Las superficies con recinto usan dos backends de VM:

• microVM para el terminal y el navegador — arranque del hipervisor en menos de un segundo desde imágenes de contenedor fijadas por digest.
• QEMU para el escritorio Linux completo, que necesita un dispositivo de pantalla del que la microVM carece.

Las superficies móviles las gestiona el host y declaran directamente la frontera más débil:

• Android controla el emulador de Google a través de ADB.
• iOS crea y posee un dispositivo CoreSimulator en un Mac que actúa como host y lo controla a través de WebDriverAgent. El dispositivo y sus datos se eliminan cuando se cierra el rig, pero su red sigue la del Mac que lo aloja.

Los rigs con recinto escriben en una capa desechable superpuesta a una imagen base de solo lectura, de modo que un rig no puede cambiar aquello desde lo que arranca el siguiente. Un rig de iOS posee un dispositivo CoreSimulator desechable que se elimina al cerrarse el rig. Android se conecta a un emulador del host que sobrevive a la sesión.

Salida denegada por defecto

La red de un rig empieza en nada. Los hosts se admiten rig a rig mediante una puerta que el huésped no puede eludir: las únicas salidas de la máquina son las que creó la configuración de arranque. Un terminal con recinto recibe la base de referencia de desarrollo (registros de paquetes, hosts de código, los repositorios espejo de apt); un rig de navegador admite el sitio del producto (usectrl.dev) y arranca en una página file:// local que no necesita salida; todo lo demás se rechaza en el momento de la conexión.

Android e iOS no están cubiertos por esta puerta. Su emulador y su simulador del host usan la red del host del servidor, así que la interfaz y el informe de capacidades marcan la salida como no aplicada y nunca ofrecen un control engañoso de «reiniciar sin restricciones».

La salida y las credenciales son una única política vista desde dos lados: el bróker de credenciales (más abajo) no emitirá un token para un host al que el huésped no pueda llegar.

Todo lo que un rig lee se trata como contenido no confiable: el texto de las páginas, el DOM y los árboles de accesibilidad, los volcados de interfaz y la salida de consola llegan al agente delimitados por una regla permanente de «esto son datos, no instrucciones». La delimitación es el marco; la puerta de salida es la aplicación que hay detrás.

La entrada pasa por el hipervisor; la captura, por el huésped

En la superficie de escritorio, los eventos de teclado y puntero los inyectan los propios dispositivos de entrada virtuales del hipervisor. El huésped nunca ejecuta un demonio privilegiado capaz de sintetizar entrada, así que comprometer el software del huésped no le entrega un teclado al atacante. La captura fluye en sentido contrario, a través de un pequeño agente sin privilegios dentro del huésped, porque el huésped puede escalar los fotogramas antes de que crucen la conexión.

Dos canales de visualización

La persona que observa y el modelo que dirige tienen necesidades opuestas, así que un rig sirve dos flujos independientes:

• El canal humano es a resolución completa con el tamaño de tu pantalla, se renegocia cuando cambias el tamaño y lo retransmite el servidor como bytes opacos: el servidor nunca descodifica un fotograma, porque un descodificador de vídeo en la ruta de las peticiones es lo que le impediría responder a las RPC.
• El canal del agente son imágenes estáticas reducidas y limitadas a un tamaño cómodo para el modelo, una imagen por resultado de herramienta, y durante la compactación se descartan los fotogramas más antiguos mientras sobreviven sus descripciones de texto.

Ninguno de los dos canales cede por el otro: tú obtienes una imagen fluida y el modelo, una barata.

La toma de control es un punto de paso obligado, no una petición

El control exclusivo se aplica en el único punto por el que pasa cada acción, no pidiéndole al modelo que se porte bien. Mientras lo tiene una persona, el servidor rechaza las acciones que mutan del agente. El agente conserva sus verbos de observación (capturas de pantalla, extracción) para poder narrar lo que estás haciendo, y se le informa de la toma de control por su canal de dirección en lugar de dejar que la descubra con clics rechazados. Hacer clic y escribir en el lienzo funciona siempre que nadie más tenga el bloqueo, o cuando lo tienes tú; la etiqueta de estado dice Tienes el control. Cada evento de entrada —tuyo y del agente— queda en un registro de auditoría por rig con su principal y una secuencia monótona, de modo que «quién hizo ese clic» sigue teniendo respuesta cuando la máquina ya no está.

El contenido cruza la frontera; las máquinas siguen separadas

Copiar y pegar funcionan en ambos sentidos, y arrastrar archivos hacia dentro y hacia fuera también, pero un rig es otro ordenador y el diseño nunca finge lo contrario.

El portapapeles se transporta a petición, no se replica de forma continua. Pulsa la combinación de copiar sobre un rig y se le indica al huésped que copie; después, lo que haya puesto en su portapapeles —texto, una imagen, una lista de archivos— se recupera y se coloca en el tuyo. Pegar envía el mismo contenido en sentido contrario y luego pulsa pegar dentro del huésped. Nada se sincroniza en segundo plano: una contraseña que copias en tu propia máquina no llega en silencio al interior de una VM porque se dispare un temporizador.

El cruce se controla por usuario y por dirección, de forma independiente. Pegar en un rig está permitido de forma predeterminada; copiar desde un rig pregunta primero (un permiso de diez minutos, o Permitir siempre en Ajustes → Servidor → Rigs → Acceso al portapapeles). Nunca es una configuración de espacio de trabajo: un miembro no puede dar su consentimiento por el portapapeles de otro miembro.

En macOS la combinación de cruce es ⌘C/⌘V, que no es ambigua: ⌃C sigue llegando a un shell del huésped como la interrupción que es. En Windows y Linux ambas combinaciones son la misma pulsación, así que el huésped la recibe sin cambios y tu portapapeles solo se sobrescribe cuando el del huésped ha cambiado de verdad. Una interrupción sigue siendo una interrupción.

Los archivos arrastrados hacia dentro se copian en la carpeta de recepción de la máquina y luego se le ofrecen. Lo que significa «ofrecer» depende de lo que se pueda hacer honestamente: una página de navegador recibe un evento de soltado real en el punto donde sueltas, así que una zona de subida se comporta exactamente como lo haría con un archivo local; un escritorio recibe los archivos en ~/Drops con sus rutas en el portapapeles, porque ningún host puede sintetizar un arrastre hacia un conjunto de herramientas de Linux arbitrario sin ejecutar un demonio privilegiado dentro del huésped, que es precisamente lo que este diseño se niega a tener. El resultado indica qué ha ocurrido, así que un CSV soltado en una zona de subida nunca se notifica como subido cuando en realidad solo es un archivo en una carpeta. Si se suelta en un terminal con recinto, el archivo se copia dentro y se escribe su ruta en el huésped en el indicador del terminal, que es lo que un shell puede usar de verdad.

Los archivos arrastrados hacia fuera funcionan en la superficie de escritorio, donde el protocolo de arrastre de X11 permite leer la carga útil mientras el arrastre está en curso. Inicia un arrastre dentro del huésped, sácalo del lienzo y los archivos se traerán a tu máquina y se entregarán al sistema operativo como un arrastre real. Copiar archivos en el gestor de archivos del huésped y pegarlos en el host funciona igual. La superficie de navegador deliberadamente no ofrece esto: un navegador sin interfaz gráfica no tiene ninguna selección de arrastre que leer, y la señal más cercana disponible —la selección de texto de la página— no es prueba de un arrastre en absoluto, así que actuar según ella secuestraría clics normales.

Todo lo que se lee de un huésped sigue siendo contenido no confiable: el texto del portapapeles llega a un modelo dentro de la misma delimitación que una extracción de página, y el registro de auditoría anota que hubo un pegado y cuánto contenido había, nunca lo que decía.

Las credenciales nunca viven en el huésped

git push funciona desde un terminal con recinto que hayas abierto tú, y aun así el huésped no almacena ningún token de host de código. Guarda un único secreto por VM cuyo único poder es pedir al bróker de credenciales del host —a través de un túnel que el host controla— un token de corta duración y limitado al repositorio, por operación, con límite de frecuencia, acotado por la misma lista de hosts permitidos que la salida y revocado en el momento en que se cierra el rig. Una máquina hecha para ser desechada no debe contener nada que merezca la pena robar.

Lo que puede hacer ese token se fija al abrir el rig. Un rig de terminal que abre una persona recibe un token de escritura, acotado por el acceso propio de ese miembro al host de código. Un rig que abrió un agente recibe uno de solo lectura: un asistente de credenciales de git no distingue un push de un fetch, así que la regla de push no se puede consultar en cada push dentro de un huésped, como hace la pasarela de ejecuciones de agentes en el host.

El worktree de un rig es un satélite

Cuando un rig lleva tu repositorio, el worktree del host sigue siendo la referencia autorizada. La copia se sincroniza hacia dentro al arrancar (con los secretos como los archivos .env excluidos), y los commits solo vuelven cuando lo pides: se recuperan en refs/rigs/<id>/*, nunca se suben al remoto ni se extraen al árbol de trabajo. Nada dentro de una VM puede mover tu rama ni tocar tu árbol de trabajo; fusionar lo que ha producido un rig es siempre una decisión humana que se toma en el host.

Puertos sin agujeros

Un servidor de desarrollo iniciado dentro de la VM del terminal se vuelve accesible —en tu máquina, en el Navegador (VM), opcionalmente en tu LAN y, si quieres, bajo un dominio de desarrollo con HTTPS— sin abrir nunca la máquina. El mapa de puertos del hipervisor se fija al arrancar, así que todo el reenvío posterior viaja por dos canales estrechos controlados por el host: un multiplexor entrante creado de antemano que se niega a conectar con nada en lo que el huésped no esté escuchando realmente, y túneles inversos que el host mantiene abiertos para las conexiones iniciadas por el huésped. El HTTPS de dominio de desarrollo termina en el servidor con una autoridad emitida localmente cuyas claves nunca entran en ningún huésped. La mecánica está en Reenviar puertos desde un terminal.

Las máquinas están acotadas por construcción

Un rig no puede convertirse en una mascota:

• un TTL máximo que el huésped no puede ampliar;
• una escalera de inactividad —poner en pausa (vCPU detenidas, RAM residente) tras la ventana de inactividad y cerrar al doble de esa ventana— en la que un terminal abierto o un visor que esté observando cuenta como «en uso»;
• un presupuesto de memoria contado en megabytes residentes, no en sesiones, porque una VM en pausa libera CPU y conserva cada byte de RAM; se expulsa primero la máquina menos usada recientemente, y nunca una que alguien esté dirigiendo u observando;
• la destrucción al apagar el servidor, más un barrido de huérfanos marcados por propietario en el siguiente arranque, de modo que un servidor caído nunca deje abandonado un hipervisor que no responde a nadie.

Los primeros arranques descargan la imagen fijada de la máquina; después, el servidor guarda en caché en segundo plano una copia ya extraída, así que todas las máquinas posteriores de ese tipo arrancan en segundos y un terminal con recinto aparece con una base de herramientas CLI al estilo de un runner alojado en GitHub ya instalada —compiladores, Python, jq, herramientas de archivo—, no una caché de herramientas por lenguaje ni Docker. La imagen de Ordenador incorpora esa misma base de herramientas CLI en el momento de compilarse, junto a XFCE y los navegadores.

Tres navegadores, no uno

«En mi máquina funciona» es una afirmación sobre un único motor de renderizado. Por eso un rig de navegador no es «el navegador», sino Chromium, Firefox o WebKit, elegido cuando lo abres, y un rig ejecuta el que se eligió al abrirlo durante toda su vida. Una conversación puede tener uno de cada: abrir Firefox (VM) junto a Chromium (VM) te da dos máquinas, y apuntar ambas a la misma página es la comparación. WebKit se acerca a Safari tanto como cualquier cosa que funcione en Linux: mismo linaje de motor, así que detecta los huecos con los que topan los usuarios de Safari.

Los verbos son idénticos en los tres; los protocolos que hay debajo no lo son, y las diferencias se declaran en lugar de disimularse. Chromium habla el DevTools Protocol y empuja los fotogramas, así que su vista en directo no cuesta nada mientras la página está quieta. Firefox habla WebDriver BiDi y WebKit habla WebDriver clásico, y ninguno de los dos tiene transmisión continua de fotogramas, así que sus vistas en directo funcionan por sondeo: unos pocos fotogramas por segundo, que es lo adecuado para observar una página y no para ver una animación. Cuando un motor no puede hacer algo de verdad (Firefox no tiene recarga que evite la caché; WebKit no puede ver la salida de consola registrada antes de que una página termine de cargarse), la respuesta lo dice en lugar de hacer otra cosa en silencio.

Dónde viven los rigs en el producto

Un rig no es, deliberadamente, un destino global. La vista en directo es una pestaña en el espacio o la PR donde ocurre el trabajo, acotada a esa conversación, así que tu pestaña y las llamadas browser_use del agente se dirigen a una máquina (una por motor, en la superficie de navegador). Que los rigs puedan arrancar o no es una propiedad del host, así que las capacidades, las imágenes, las imágenes personalizadas por espacio de trabajo y la lista de máquinas en ejecución están en Ajustes → Servidor → Rigs. Dirigir un recinto es su propia clase de acción de barandilla, así que un espacio de trabajo, un agente o un espacio pueden permitirla, exigir aprobación o denegarla directamente; los modos de solo lectura la deniegan por completo.