TaskGoblin es un agente en la nube, lo que significa que la pregunta más importante de todas — ¿dónde se ejecuta mi código? — tiene una sola respuesta: en un sandbox en la nube aislado, nunca en el portátil de nadie. Esta página explica qué es ese sandbox, por qué está aislado y cómo sigue estándolo a medida que tu equipo crece.
Qué es el sandbox
Un sandbox es un contenedor aislado en la nube con una copia de tu repositorio. Cuando delegas una tarea, el agente se ejecuta dentro de ese contenedor — lee y edita archivos, ejecuta comandos e inspecciona el repositorio allí, sin acceso a tu máquina y sin depender de que esté encendida.
Como el sandbox vive en la nube, el trabajo es asíncrono por naturaleza: asignas una tarea y te vas, y el agente sigue trabajando estés mirando o no.
Aislamiento: una frontera por organización
El trabajo de cada organización se ejecuta dentro de su propio sandbox. Esa frontera es el núcleo del aislamiento de datos de TaskGoblin — una organización nunca puede leer ni escribir el código, los repositorios o el historial de ejecuciones de otra. El agente solo ve los espacios de trabajo, repositorios y proyectos que conectas explícitamente; desconecta una conexión y pierde el acceso al instante.
Persistencia: recuerda la configuración, no solo la tarea
El sandbox es persistente y se reutiliza entre los mensajes de un mismo hilo. Un seguimiento sobre el mismo issue aterriza en un entorno que ya tiene el repositorio clonado y el estado de la ejecución anterior en su sitio — así el agente retoma rápido en lugar de empezar desde una caja vacía cada vez. Esto es lo que hace que iterar sobre una tarea se sienta continuo en lugar de repetitivo. (Para saber cómo esa continuidad traslada decisiones entre ejecuciones, consulta Cómo funciona el agente sobre hilos y memoria de traspaso.)
Los secretos se quedan fuera del agente
El agente nunca ve tus credenciales. El acceso a git dentro del sandbox se aprovisiona por organización en tiempo de ejecución — un token OAuth de GitLab o un token de instalación de GitHub recién emitido — y se inyecta en el entorno alrededor del agente en lugar de entregársele como algo que leer. El agente puede usar el acceso que necesita para clonar y hacer push, sin que tus secretos entren nunca en su transcripción ni en su contexto.
Es una frontera deliberada, no un efecto secundario: la credencial está disponible para las herramientas de git del sandbox, pero nunca forma parte del material que el agente lee o sobre el que razona.
Sandboxes personalizados
En los planes de equipo puedes traer un sandbox personalizado — una imagen de contenedor precargada con el conjunto de herramientas, los paquetes del sistema y los servicios que tu proyecto necesita para compilar y probar. Cuando el trabajo del agente depende de algo más que una copia limpia (un runtime concreto, una base de datos, herramientas de compilación privadas), un sandbox personalizado significa que el entorno está listo en el momento en que arranca la tarea, y que los cambios del agente pueden verificarse en un montaje realista.
Sandboxes autoalojados
Los equipos con requisitos de cumplimiento o de residencia de datos pueden ejecutar sandboxes en su propia infraestructura. El plano de control sigue programando e impulsando el trabajo, pero el contenedor donde se descarga y ejecuta tu código vive dentro de tu entorno — así el código fuente, los artefactos de compilación y el estado de ejecución nunca salen de una frontera que tú controlas. Es la opción a la que recurrir cuando "en la nube" tiene que significar tu nube.
A dónde ir después
- Cómo funciona el agente — el flujo completo del disparo al merge request, los hilos y la memoria de traspaso.
- Asigna trabajo al agente — todas las formas de lanzar una ejecución y cómo el trabajo en paralelo usa un sandbox por tarea.
- Loops — ejecuciones recurrentes que usan el mismo modelo de sandbox con una cadencia.