O TaskGoblin é um agente na nuvem, o que significa que a pergunta mais importante de todas — onde o meu código roda? — tem uma única resposta: em um sandbox na nuvem isolado, nunca no notebook de ninguém. Esta página explica o que é esse sandbox, por que ele é isolado e como ele continua assim conforme seu time cresce.
O que é o sandbox
Um sandbox é um contêiner isolado na nuvem com uma cópia do seu repositório. Quando você entrega uma tarefa, o agente roda dentro desse contêiner — ele lê e edita arquivos, executa comandos e inspeciona o repositório ali, sem acesso à sua máquina e sem depender de ela estar ligada.
Como o sandbox vive na nuvem, o trabalho é assíncrono por natureza: você atribui uma tarefa e vai embora, e o agente continua trabalhando esteja você olhando ou não.
Isolamento: uma fronteira por organização
O trabalho de cada organização roda dentro do seu próprio sandbox. Essa fronteira é o núcleo do isolamento de dados do TaskGoblin — uma organização nunca pode ler nem escrever o código, os repositórios ou o histórico de execuções de outra. O agente só enxerga os workspaces, repositórios e projetos que você conecta explicitamente; desconecte uma conexão e ele perde o acesso na hora.
Persistência: ele lembra da configuração, não só da tarefa
O sandbox é persistente e reutilizado entre as mensagens de uma mesma thread. Um follow-up na mesma issue chega em um ambiente que já tem o repositório clonado e o estado da execução anterior no lugar — então o agente retoma rápido em vez de começar de uma caixa vazia toda vez. É isso que faz iterar em uma tarefa parecer contínuo em vez de repetitivo. (Para saber como essa continuidade carrega decisões entre execuções, veja Como o agente funciona sobre threads e memória de repasse.)
Os segredos ficam fora do agente
O agente nunca vê suas credenciais. O acesso ao git dentro do sandbox é provisionado por organização em tempo de execução — um token OAuth do GitLab ou um token de instalação do GitHub recém-emitido — e injetado no ambiente em volta do agente, em vez de entregue a ele como algo para ler. O agente pode usar o acesso de que precisa para clonar e dar push, sem que seus segredos entrem no transcript ou no contexto dele.
Essa é uma fronteira deliberada, não um efeito colateral: a credencial fica disponível para o ferramental de git no sandbox, mas nunca faz parte do material que o agente lê ou sobre o qual raciocina.
Sandboxes personalizados
Nos planos de time você pode trazer um sandbox personalizado — uma imagem de contêiner pré-carregada com o toolchain, os pacotes de sistema e os serviços que seu projeto precisa para compilar e testar. Quando o trabalho do agente depende de mais do que um checkout puro (um runtime específico, um banco de dados, ferramental de build privado), um sandbox personalizado significa que o ambiente está pronto no instante em que a tarefa começa, e que as mudanças do agente podem ser verificadas em um cenário realista.
Sandboxes auto-hospedados
Times com requisitos de conformidade ou de residência de dados podem rodar sandboxes na própria infraestrutura. O plano de controle continua agendando e conduzindo o trabalho, mas o contêiner onde seu código é baixado e executado vive dentro do seu ambiente — então código-fonte, artefatos de build e estado de execução nunca saem de uma fronteira que você controla. É a opção a escolher quando "na nuvem" precisa significar a sua nuvem.
Para onde ir depois
- Como o agente funciona — o fluxo completo do gatilho ao merge request, threads e memória de repasse.
- Atribua trabalho ao agente — todas as formas de iniciar uma execução e como o trabalho paralelo usa um sandbox por tarefa.
- Loops — execuções recorrentes que usam o mesmo modelo de sandbox em uma cadência.